本文主要是介绍记一次生产环境Java服务synchronized死锁的处理过程，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
案例
客户反馈网址响应太慢，有时直接无响应。仿佛卡死一般。
驱动包：mysql-connector-java 5.1.32
过程
看的第一眼，感觉这个问题简单。
响应慢，肯定是系统在进行full gc STW导致系统变慢。
内存泄漏呗！再或者就是网络拥堵。
1、查看服务器网络
直接使用finalshell连接服务器，查看网络带宽使用情况
服务器的带宽是上传10M，下载1M，使用率并不高。所以排除网络原因。
2、查看java服务的堆栈情况
使用阿里arthas工具查看，执行dashboard命令
看样子不是在full gc，老年代虽说占用了80%，但是还不足以频繁full gc。
3、随后查看tomcat日志
tomcat启动增加了-verbose:gc参数，如果发生gc，则控制台会打印gc信息。
但是并没有发现频繁的gc信息。
好了，现在排除内存泄漏情况
4、查看线程栈
继续使用arthas,执行thread --all命令
发现有很多BLOCKED阻塞状态的线程。这里没有截上图
继续使用thread -state BLOCKED --all命令，筛选出阻塞的线程
发现有199个线程被阻塞，而且全都是tomcat的服务线程。
说明：我的springboot的tomcat没有配置最大线程数，默认是200。
这说明200条线程被阻塞了199条，只有1条线程能提供服务。不卡才怪
5、继续检查线程栈
继续使用arthas,执行thread -b命令
发现arthas提示了but blocks 199 other threads 说明这个位置阻塞了199条其他的线程的运行。
此线程行前面有 locked 说明使用了synchronized锁。
到这里很明显，程序发生了死锁
6、检查代码
上一步可以发现出问题的是TfWarehouseOutServiceImpl类的nextWarehouseCode方法
找到源码，发现是获取订单号的方法。我们都知道订单号是不能重复的，所以要加synchronized锁。
当然了，单机模式这么做是可以的。分布式要用分布式锁。
此时有疑问了。按理说应该最少两个锁才会发生死锁啊，相互拿到对方的锁。可是这里只有一把锁，怎么也会死锁呢？
继续看线程栈
在arthas上看的不清楚，我用jstack pid >thread_stack.txt把栈全部导出来了
发现199个线程都在等待0x0000000742f17958这个锁，那这个锁被哪个线程拿着呢？
发现是被http-bio-7085-exec-179个线程拿着呢，但是它拿着锁，一直在等待mysql socket tcp的响应
what？？？卡在这了。
原因找到了：这个线程在mysql查询的时候拿不到数据，一直在这里等着。也不释放锁，导致其他199的线程都进不来 。
而这段代码正好是在synchronized方法体中
7、查询解决办法
出现的原因可能是网络抖动、防火墙或是其他原因，导致了应用和mysql的连接断开。
但是应用和mysql不知道已经断开了，还在接受等待消息。
这也是mysql驱动的一个bug，有人已经提交到了官方MySQL Bugs: #74739: ReadAheadInputStream hangs on socket read
mysql连接器的官方文档：MySQL :: MySQL Connector/J 8.0 Developer Guide :: 6.3 Configuration Properties
类似事件：CPU占用高系统反应慢之问题定位 - lewisat - 博客园
8、解决办法
1、增加tomcat最大线程数。
默认是200条，现在我设置为500条。就算卡住了199条线程，我还有301条能提供服务，系统不会卡死。保证可用性。
2、设置mysql的socket连接超时时间。
设置socketTimeout的值（默认是0）
这样就算线程再在synchronized方法块内因为数据库查询没有返回，被卡住，等socket超时（3分钟）之后会抛出异常。
会释放锁，之后的线程就能继续访问了synchronized方法块了。
3、打开数据库连接超时回收，防止连接泄漏
增加数据库连接超时回收功能，更上一层保险，防止连接泄漏。
就是为了避免连接被线程长时间使用，迟迟不归还（阻塞着），连接池内的连接数量会一直达到max-active的值。
从而导致其他线程获取不到可用的连接，没有连接可用，服务就挂掉了。
4、使用ReentrantLock锁
替换synchronized同步代码块，可以在tryLock(long timeout, TimeUnit unit)时设置等待时间，或lockInterruptibly设置为可中断的
5、使用redis分布式锁
也是利用超时时间去释放锁
修改之后的一段时间
又出现了上述的问题。后来发现了数据库连接验证为false，也就是不需要验证连接
我怀疑可能是因为连接池的空闲检查线程设置的时间太长，没有及时清除掉已经失效的数据库连接。
Java服务拿到了已经失效的数据库连接，导致问题的出现。
现在设置spring.datasource.test-on-borrow=true，也就是java服务使用数据库连接之前先进行一下select 1测试连接是否正常，在进行业务的sql执行。
又经过了一段时间
问题还是有，最后没办法了。只能改代码。
把获取单号的逻辑，改成了从redis中获取，代码如下：
@Override@Transactionalpublic void nextWarehouseCode(TfWarehouseOut out1, String date) {//获取单号后缀（后四位）String key="WAREHOUSE_CODE_"+date+"_"+out1.getOrganization().getId();redisTemplate.setKeySerializer(stringRedisSerializer);redisTemplate.setValueSerializer(genericToStringSerializer);Long maxCode = redisTemplate.opsForValue().get(key);if(maxCode!=null){log.info("获取出库单号(redis)：key:"+key+",maxCode:"+maxCode);//redis自增maxCode = redisTemplate.opsForValue().increment(key, 1);//拼接单号String current = new SimpleDateFormat("yyyyMM").format(Calendar.getInstance().getTime());String code = "GC" + current + new DecimalFormat("0000").format(maxCode);// 更新单号out1.setWarehouseOutCode(code);this.add(out1);}else{log.info("开始获取出库单号(数据库)");synchronized (lock) {//数据库查询,使用原生sql查询String sql = "SELECT t.WAREHOUSE_OUT_CODE FROM Tf_Warehouse_Out t WHERE " +" t.organization_id=" + out1.getOrganization().getId() + " AND t.WAREHOUSE_OUT_CODE LIKE 'GC" + date + "%' AND" +" t.out_Date IS NOT NULL ORDER BY WAREHOUSE_OUT_CODE DESC";List<String> list = maxBaseRepository.findByNativeSql(sql, null, -1, 1);if (!list.isEmpty() && StringUtils.isNotBlank(list.get(0))) {//取出四位后缀maxCode = Long.parseLong(StringUtils.right(list.get(0), 4)) + 1L;} else {//不存在则从1开始maxCode = 1L;}log.info("获取出库单号(数据库)：key:"+key+",maxCode:"+maxCode);//拼接单号String current = new SimpleDateFormat("yyyyMM").format(Calendar.getInstance().getTime());String code = "GC" + current + new DecimalFormat("0000").format(maxCode);// 更新单号out1.setWarehouseOutCode(code);this.add(out1);//单号后缀保存到redis,保留1个月+加上随机值，防止key同时过期，缓存雪崩redisTemplate.opsForValue().set(key, maxCode, 30*24*60*60+(int)(Math.random()*3600), TimeUnit.SECONDS);}}}经过了一段时间，问题不再出现。
再后来接触过并发编程后，发现ReentrantLock也比较适合解决这个问题，使用它的tryLock(long timeout, TimeUnit unit)可以解决死锁问题
这篇关于记一次生产环境Java服务synchronized死锁的处理过程的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
