java问题定位总结

本周遇到了两起java问题的定位，特此总结一下：

场景一：Jenkins有大量的job无法被调度，运维人员怀疑是jenkins for kubernates插件有bug，并通过Jstack捕获了一个thread dump的命令，发现jvm里面有大量线程，正在等一个重入锁，于是让我分析原因。

  

Dump文件比较大，从文本文件分析较费劲，不过也能找出来有一个线程占用了锁，其他有100+线程都在等待这个锁。可是根据dump的中这个占有锁线程所处的函数来看，只是在一个map的get方法，根本看不出来有阻塞的情况。于是找运维人员又导出了一份dump(一小时后)，发现这个dump就只有10+个线程在竞争锁了，而且占有锁的线程是另外一个线程。查看了对应此位置的源代码，在jenkins addnode的位置，确实有注释写了此处会有锁竞争的问题，但可能不一定是任务不能调度的原因。由于jenkins已经被重启，只能后续出现问题后再观察

 

总结在定位线程的问题时：可以通过Jstack捕获现网的线程堆栈，具体方法可参考下面的文章

https://confluence.atlassian.com/confkb/how-to-analyse-thread-dumps-788039144.html

他建议的是dump出很多个，十秒dump一个，dump六次，然后建议通过"Thread Dump Analyzer" (TDA),这个工具辅助分析，这个工具可以清晰的看到多个dump之间的长期运行的线程，并可以智能的把竞争严重的锁及线程标红出来。

 

场景二：发现kubernates里跑的pod虽然长期在运行，但显示restart了多次

对此我怀疑还是因为java的jvm过大后，被kubernates的mem limit给处理掉了。于是暂时给jvm设置了2g的最大内存，以及给pod设置了3g的mem limit。待观察后续是否还会被restart.

 

总结在定位内存的问题时：如果是springboot项目，可以通过actuator对外暴露http/jmx数据，使用方法可参考http://www.callicoder.com/spring-boot-actuator.  那么这些jvm的数据对外暴露后，我们既可以使用promethous+grafana+alertmanager监控和告警，也可以使用visualvm/jconsle工具去分析内存被占用的原因

 

当然，通过pod limit保护java容器也是必要的，不能让容器内存无限增大。