从报表A中发现数据丢失，然后找到程序运行的日志，发现日志只有一小部分，平常12G，今天只有243M
但是报表B中发现程序运行完毕。因此可以推断程序在运行，但是日志丢失了。
根据proc文件系统来找相关的信息
发现几个log文件
打开文件发现确实是今天丢失的文件，Tail –f一下文件发现，有一个线程一直在等待
说明文件中的线程发生了死锁。
使用Java内存分析命令（jstack 5669）分析内存：发现有SocksSocketImpl服务locked
看一下日志丢失前出现异常的地方：也有socket导致的异常
因此需求解决到这个异常，因为这个异常导致还有一个子进程处于死锁状态。
由此可以发现，内存中有一个对象发生了异常，但是这个异常没有很好的捕获处理，导致了线程一直处于死锁状态。
最后查看源代码发现，等待主要是因为变量aliveMutThreadNum没有进行原子操作，
如下图：索然在 aliveMutThreadNum 变量操作的时候使用了加锁的方式，但是 synchronized依然不是最保险的形式，因为
1 synchronized一般主要用来获取类锁
2 虽然方法同步了，但是如果没有在合适的地方使用方法，结果依然会造成死锁。本次死锁就是因为在捕获异常的时候没有在finally里面对aliveMutThreadNum进行处理，虽然调用相关的方法，但是因为程序没有执行到这一步，仍然导致了死锁。
正确的做法应该是使用volatile关键字进行修饰：并且在try catche finally的finally里面进行处理。
另外：1.程序计数器最好不用这么写，最好使用countdownlatch 类来进行处理。
2.如果发生了死锁，应该可以手动命令，让Java跳过死锁部分，继续进行执行其他的程序，可以使用hotswap来达到这个目的