无论是 Java 大数据系统运维人员，还是Java平台开发 运维 人员、亦或Java App开发运维人员，都会遇到各种各样的Java应用层面的问题。那Java应用层面的问题应该如何定位排查呢？有没有什么好的工具和方法呢？

针对Java应用层面的问题，我认为可以从如下几个层面去定位分析：

一. Arthas大法

arthas是阿里开源的一款Java在线问题诊断工具，可以说优秀之极，笔者认为任何Java应用层面的问题都应该首先考虑是否可以使用arthas进行定位。

Arthas可以定位哪些问题？

Arthas READEME介绍了这款工具可以帮助你做下面这些事:

• 这个类从哪个 jar 包加载的？为什么会报各种类相关的 Exception？
• 我改的代码为什么没有执行到？难道是我没 commit？分支搞错了？
• 遇到问题无法在线上 debug，难道只能通过加日志再重新发布吗？
• 线上遇到某个用户的数据处理有问题，但线上同样无法 debug，线下无法重现！
• 是否有一个全局视角来查看系统的运行状况？
• 有什么办法可以监控到 JVM 的实时运行状态？

Arthas直接attach到JVM是否会造成JVM卡顿等？

从目前笔者近10次线上使用的经验来看，Arthas直接attach JVM都没有给JVM造成很大的影响。可以比较放心的使用。

笔者使用Arthas定位过哪些方面的问题？

笔者使用Arthas主要定位了很多大数据系统层面的问题，比如 HBase 服务、Hive服务等运行中的问题，这里简单的列举几个问题，并使用文章进行案例分享。

1. 定位线上Hive meta store执行addPartition等命令耗时长的问题。

2. 定位线上Hive MapJoin作业运行疑似卡住（长时间没任何输出）的问题。

3. 定位线上HBase表级别Metrics没有正常输出的问题。

4. 定位线上HBase客户端访问hbase:meta表超时的问题。

这些问题的定位过程主要使用了Arthas的watch、monitor、trace以及stack等命令，在定位问题的过程中，核心体现了arthas的简单。

二. 使用log4j的debug/trace功能

除了使用arthas之外，不得不说log4j也是定位很多大数据系统（比如 hadoop 、hbase等）问题的一把利器。笔者就使用log4j的debug/trace功能定位了很多起HBase客户端访问HBase元数据超时的问题，笔者也看到过很多运维同学使用log4j debug/trace功能定位系统问题的真实案例。

对于log4j/log4j2技术本身来说，并没有太多需要讲解的，这里重点就一个问题做下说明，就是log4j中将info级别下调为debug级别并不要求全局范围的调整，而可以就包级别甚至类级别进行调整。这样的话，就不会造成短时间大量日志产生。这里以log4j简单举个示例来说明这个问题：

 log4j.logger.com.xxx.action= INFO,JobLog  //com.xxx.action 可以为具体的类也可以是包
log4j.appender.JobLog=org.apache.log4j.RollingFileAppender

//下面这个log4j配置放在HBase客户端conf内，就可以只针对HBase客户端的日志将打印级别调整为debug
log4j.appender.HBASECLIENT=org.apache.log4j.ConsoleAppender
log4j.appender.HBASECLIENT.Threshold = DEBUG
log4j.appender.HBASECLIENT.layout=org.apache.log4j.PatternLayout
log4j.appender.HBASECLIENT.layout.ConversionPattern=[QC] %p [%t] %C.%M(%L) | %m%n
log4j.logger.org.apache.ha do op.hbase=DEBUG,HBASECLIENT  

至于案例，笔者会结合上文中定位线上HBase客户端访问hbase:meta类超时的案例进行说明。

三. jstack/jmap等工具

jstack是arthas出现之前定位 线程 问题最常见的一个工具，比如结合top -H排查消耗CPU最多的某个线程，比如查看系统异常的时刻都有哪些线程在工作，或者查看是否存在死锁等。这里笔者简单分享一个使用jstack分析问题的一个案例：

使用jstack排查HBase Compaction问题案例

这个案例实际上是比较复杂的，为了说明jstack的作用，笔者只能掐头去尾，将关系到jstack的部分内容拿出来说说。

问题背景是这样的，有一天某个HBase集群忽然所有业务写入都失败了，HBase服务拒绝了所有的写入请求。经过分析，是因为HBase集群中某张表的Compaction出现了异常，异常的表现就是这个表的compaction都执行了10小时以上还没有结束，正常情况下一次compaction最多就1个小时左右，Compaction无法正常完成会导致compaction线程无法释放，其他表的compaction无法正常进行。

因为写入数据生成的文件无法合并，会导致其他表的文件数量不断攀升，一旦文件数量超过阈值，系统就会阻塞写入。那这里一个核心问题就是为什么问题表的compaction会持续10个小时还没有结束呢？

为了解答这个问题，就需要派上jstack工具了。使用jstack工具查看当前HBase节点的工作线程，如下图所示：

经过几次间隔时间的jstack，可以确认所有compaction线程都卡在同一个地方，即PREFIX_TREE编码的地方。最后和HBase社区确认，PREFIX_TREE编码存在bug会导致compaction卡住。至此，这个问题基本上就得到了定位。

但是不得不说，自从arthas出来之后，使用arthas的threads/thread功能可以一定程度上代替jstack，使得jstack的用途受到一定限制。对于jmap来说，依然是分析Java应用内存问题的必不可少的一把利器，这部分内容在JVM问题分析部分有详细介绍，在此不再赘述。

四. 其他

除了上述将到的几种分析Java应用问题的系统方法之外，应该还有很多比较零散的分析方法。比如对于某些场景下出现 NoSuchFiledError/NoSuchMethodError/ClassNotFoundException ，有可能是类在jar中不存在，也有可能存在jar包冲突。针对后者，最简单的方案就是找到哪些jar包中都包含目标类，即找到冲突的主体，然后再看如何解决冲突。怎么找呢？这里简单介绍一种方法：

 #!/bin/sh
 
find_dir=$1
find_key=$2
 
jars=`find $find_dir -name '*.jar'`
for jar in $jars
do
   ret=`jar tvf $jar |  grep  $find_key`
     if [ "$?" = "0" ]; then
          echo -e "${jar}: ${ret}"
     fi
done
 
wars=`find $find_dir -name '*.war'`
for war in $wars
do
   ret=`jar tvf $war | grep $find_key`
     if [ "$?" = "0" ]; then
          echo -e "${war} : ${ret}"
     fi
done
 
libisthanksdeMacBook-Air:target libisthanks$ bash findclass.sh . QuotaFilter
./hbase-client-1.2.6.jar: 2693 Fri May 22 17:11:52 CST 2020 org/apache/hadoop/hbase/quotas/QuotaFilter.class
./hbase-client-1.2.6-sources.jar: 3030 Fri Jan 29 15:33:22 CST 2016 org/apache/hadoop/hbase/quotas/QuotaFilter.java
  

今天分享的内容就到这里了~看到这里的小伙伴，无论你是小白还是大神，都欢迎多多 评论 、 点赞 、 互动 哦。

大家也可以将学习使用Java过程中不懂的困惑提出来，后续我会为大家讲解。

最近我也整理了一些Java资料，包含 面经分享、模拟试题和视频干货 ，如果感兴趣的话，欢迎 关注并私信 我！爱你们~