常见的Java问题排查方法(4)

　　?

　　[core dump文件]来提取出java的线程堆栈，从而具体定位到具体的代码;如有hs_err[pid].log以及core dump文件，则需要具体原因具体排查，这个比较麻烦，常见的可能会有上面的native oom(还有可能是32 bit机器，但java进程已经申请了超过3g的地址空间)，某些代码jit编译出问题了(可通过指定某些代码不让jit编译来避免，但会影响性能：-XX:CompileCommand=exclude,类名/方法名)等。

　　在上面的招还无效时，可以尝试dmesg看看是不是系统出了什么问题或系统主动杀掉过进程(例如内存超出限制等)，仍然没找到原因的话需要去翻翻应用的日志，看看是不是能找到什么线索，因为有些时候是应用上主动退出了(对于应用主动退出的问题可通过btrace来排查是不是有主动调用过System.exit)。

　　硬件资源未到瓶颈，但吞吐量上不去

　　如在压测时，出现这个现象时，首先可以看看施加压力的一端是否真的压力传递到了服务端。

　　如确认，则可以看看从server接到请求的地方开始，是不是处理线程池满了(例如假设是tomcat，最大的线程数大小是不是已经到了)，如处理线程池满了，可考虑扩大线程数大小，这个地方的排查其实有点麻烦，需要从接收请求的部分一直到纯粹的业务处理部分，看看每步的瓶颈状况，例如有些时候新建连接这种还有可能是由于系统参数的问题;

　　另外，需要看的就是锁的状况，可通过jstack -l来查看，也许是由于锁竞争激烈造成，在锁竞争激烈出现时，需要考虑使用j.u.c里的数据结构或使用无锁算法等来优化。

原文转自：http://bluedavy.me/?p=445