最近出了个故障，排查的时候耗费了很长的时间，回顾整个排查过程，经验主义在这里起了不好的作用，直接导致了整个故障排查的时间非常长，这个故障的根本原因在于BlockingQueue用的有问题，顺带展开说说Java中常用的几个BlockingQueue：ArrayBlockingQueue、LinkedBlockingQueue和SynchronousQueue。 当时故障的现象是应用处理请求的线程池满了，导致请求处理不了，于是dump线程，看线程都在做什么，结果发现线程都Block在写日志的地方，以前出现过很多次问题，去线程dump的时候看到也是一堆的block在写日志，但通常是别的原因引发的，所以这次也是按照这样的经验，认为肯定不会是写日志这个地方的问题，于是各种排查...折腾了N久后，回过头看发现持有那把日志锁的地方是自己人写的代码，那段代码在拿到了这个日志锁后，从线程堆栈上看，block在了ArrayBlockingQueue.put这个地方，于是翻看这段代码，结果发现这是个1024长度的BlockingQueue，那就意味着如果这个Queue被放了1024个对象的话，put就一定会被block住，而且其实翻代码的时候能看出写代码的同学是考虑到了BlockingQueue如果满了应该要处理的，代码里写着： if (blockingQueue.remainingCapacity() |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
