总想写点技术积累。因为最近工作比较忙，一忙一懒，找足了借口 :(
今天想简单记录一下前段时间发现在做数据清洗时遇到的问题，在处理这件事情上，感受到了许多。
大概需求是这样的：有两组数据库，每组都是分库分表的结构。从两组库中查出数据，根据规则再进行入库、清除缓存、发送消息队列。数据有几千万。
遇到这样的问题，首先想到的就是在保证数据准确的情况下做并行处理，其次想到的是尽量降低数据库的压力，再次就是可重复执行。
大概是这么写的。伪代码：
staic Connection connA = new LongDbConnectionA(); // 不做自动关闭，只做查询操作
static Connection connB = new LongDbConnectinoB(); // 不做自动关闭，只做查询操作
CountDownLatch latch = new CountDownLatch(dbACount + dbBCount);
ExecutorService service = Executors.newFixedThreadPool(MAX_THREAD_NUM);
for(a;b;c) {
service.submit(new BizRunnable()); // 具体的业务逻辑
}
latch.await();
service.shutdown();
log.info(result);
我使用了4个线程在本地做运行测试，在测试过程中偶尔发生程序hung住的问题。正好其他同学在这段时间反馈研发环境的数据库访问特别慢，所以我认为hung住也是数据库搞的鬼，也没去深究。
于是后续去线上执行了3次预跑，程序运行的很好，很快，根据日志分析也很ok，40个线程几分钟就跑完了。然后信心满满的去正式跑。
刚运行一会发现在服务器上神奇的hung住了！开始不相信是代码的问题，kill -9 pid，重来，因为可重复跑嘛。这次终于执行完成了，验证后数据正常。完事后手动clear了cache，发送消息队列。一番周章，有惊无险的搞定了事情。
但是这次在服务器上hung住绝对不可能认为是数据库的问题，那自然而然。于是跟我的头一起看代码，看了半天也没发现哪里出现了问题，感觉似乎都很正常，中规中矩的代码。
既然代码看不出来了，只能想别的办法了。回到研发环境我反复跑了几次，问题终于复现了，又见hung住。我确认还是代码的问题。于是再多次运行直到hung状态。用stack打印当前堆栈。果然，发现了deadlock。原来是最外层那个想节省数据库链接的主意导致了Connection的死锁：
Found one Java-level deadlock: ============================= "pool-1-thread-4": waiting to lock monitor 0x000000000d8fb7d8 (object 0x000000078176ea50, a com.mysql.jdbc.JDBC4Connection), which is held by "pool-1-thread-1" "pool-1-thread-1": waiting to lock monitor 0x000000000d8f8918 (object 0x00000007d75838b0, a com.mysql.jdbc.JDBC4ResultSet), which is held by "pool-1-thread-3" "pool-1-thread-3": waiting to lock monitor 0x000000000d8f89c8 (object 0x00000007d7581ea0, a com.mysql.jdbc.JDBC4PreparedStatement), which is held by "pool-1-thread-1"
今天翻文件的时候
工作完成后，才定位到问题，这事是第一次用到。也有一些感悟：
1、不要太相信自己的代码；
2、遇到异常不要想当然，要真正的去定位问题，而不是凭借主观意识去决断；多做一步，消灭BUG；
3、不容易定位的死锁问题使用jstack可以很方便的找到根源；
4、别有侥幸心理，多测试不会死，测试不足会崩。崩了，丢人。。
版权声明：本文为博主原创文章，未经博主允许不得转载。