死锁问题在 SRE 的日常的应用诊断中, 经常遇到. 遇到的大多数, 都是通过 thread dump 里面明显看到的, 因为 thread dump 默认会在最后打印出 JVM 识别出来的死锁. 对于使用 AQS 锁的情况, 获得的锁就不会打印在 thread dump 里面. 这时候, 就需要分析具体的堆栈的情况去具体识别. 这里就展示一个这样的案例.
首先, 报警显示有个机器的 Tomcat 服务线程被用光了, 已经无法再接受新的请求. 该应用其它server还是正常工作, 所以判断只是这个 server 走火入魔, 陷入了困境. 
Java 既有早期的 blocking IO (面向流的Input/output stream, 面向字符的 Reader/Writer), 又有之后加入的 NIO/ NIO 2 (Channel & Buffer). 很多应用都是使用的 早期的 blocking 的 IO. 不论是 blocking IO 还是 NIO 都要注意 socket timeout 问题, 如果不设置, 都会引起应用卡在 IO 的问题.
一般看到 java.lang.NoClassDefFoundError 时, 下一步的操作很明确: 去看看这个类为什么不存在? 不在编译路径上? 这个类文件被损坏? 真的缺少这个类? 或者缺少包含这个类的包? 基本按照这个思路都能找到解决方法. 今天遇到这个情况是, 明明这个类完好无损的就在那里, 却始终抛出这个错误.
这是本人发表在 eBay 微信公众号 eBay技术荟 上的 一系列文章, 原文地址如下. 编辑非常给力, 请查看原文, 这里只是供搜索引擎访问.
https://mp.weixin.qq.com/s/r__X4sYj6PLjPDWDulJAAw
如果原文由于某种原因不存在了, 请查看这个pdf 版本: SRE重案调查组 第六集 | 剖析Java的非常规线程死锁问题
导读
本文将分享eBay SRE部门遇到的某个非常规Java应用程序死锁问题。SRE侦探们将从最表象的问题入手，逐步分析，并重现代码，提出该类问题的解决方案，最后总结Java常规及非常规死锁问题的分析及定位，希望能对同业人员有所启发。