记一次生产环境Java服务synchronized死锁的处理过程

本文主要是介绍记一次生产环境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);}}}