利用java反射排查一次线上问题(确定问题及问题定位)

背景

hive 用的 1.1.0版本（其实这个版本bug挺多，包括执行计划串列的等等问题吧，建议大家如果选1.x版本用1.2.2吧），一下提到的代码部分如无特殊说明都是hive-1.1.0版本。

前段时间写一个hive sql 预估资源的服务（根据sql返回其读取的行数及所读文件（表）的大小，在运行时给其指定合理资源的大小，目前我们把线上所有hql转到sparksql上执行，所以要指定其资源），其实之前一直利用hiveserver2(以下hiverserver2都用hs2替代)完成。
hs2比较轻量简单，但是hs2服务不是特别稳定，用过的人都知道（包括卡死，对hdfs敏感，对avro类型文件解析也时常有问题)。
经常出现接口服务超时问题。其实有这些问题也可以暂时忍一忍，但是前段时间出现有些sql可以导致整个接口不可用的情况，实在不可忍啦，就决定重写了。然后就掉进坑了啦！

上线问题排查，定位问题sql，排查卡死原因

首先根据后台日志找到了卡死服务的sql，然后就用这个sql debug呗，sql也较为复杂（大概600-700行左右）最后定位到应该是optimizer的问题。
这个优化器大概是做什么的呢，包括join 优化呀，谓词下推呀等等十来种吧(以后我会写一篇hive Driver 执行流程的文章，会详细介绍这部分内容。)
但是为什么他会影响其他sql呢，其实hive 在compile方法加了全局锁。这个锁是Driver 类的一个全局静态锁，所以相当于

private static Object mutex = new Object();
synchronized(mutex){
    driver.compile(...)
}

这个sql 卡在了 complie中的optimizer中了，死循环了，无法释放mutex锁对象了，然后就崩盘喽。