java系统慢排查_java问题排查总结

前些天发现:http://hellojava.info/这个站点，关于java问题排查分析总结线上故障总结其实是最有价值的，好的总结就是一个系统演进历史，是团队难得的积累沉淀。

花了不少时间看了下，顺手整理了笔记：

1. Hashmap 并发情况下未加锁导致OOM

嗯，死循环很常见，OOM也会有，序列化时 HashMap.writeObject 一直执行生成巨大的数组。

2. Direct Bytebuffer

大小有限制，默认配置大小为：-Xmx，必要通过-XX:MaxDirectMemorySize 指定

虽然分配在堆外，但不能手动释放内存。。。(和.Net 很大不一样)只能被gc 释放包装类时，通过Java Reference 机制释放。

3. filechannel.map OOM

系统限制， proc/sys/vm/max_map_count 超过后OOM

4. can not create native thread OOM

ulimit、kernel.max_pid

5. 一个性能狂降cash

CodeCache is full，compiler has been disabled

server模式下默认48M，java -XX:ReservedCodeCacheSize=128m 设置大小，必要的时候调大

6. linux 2.6.23 高精度定时器引发sys高

7. jmap dump 的危险性

- jmap -dump 这个命令执行，JVM会将整个heap的信息dump写入到一个文件，heap如果比较大的话，就会导致这个过程比较耗时，并且执行的过程中为了保证dump的信息是可靠的，所以会暂停应用。 - jmap -permstat 这个命令执行，JVM会去统计perm区的状况，这整个过程也会比较的耗时，并且同样也会暂停应用。 - jmap -histo:live

这个命令执行，JVM会先触发gc，然后再统计信息。

可以使用gcore [pid] dump速度很快很多，在通过jmap jstack 从core dump 提取信息

8. 高峰重启解释执行慢，load可能长时间很高

-XX:CICompilerCount 默认2，编译线程数，可以调高

9. jvm会cache -128~127的Integer对象，而不在这个范围的则会每次new Integer。

10.  dtd/xsd 文件注意放在本地

11. jstack find wait bug thread running，pstack native stack

12. 一个方法超过8000bytes 时，将不会编译

设置：-XX:-DontCompileHugeMethods 强制编译

13. inline 编译方法大小为35bytes

14. 不建议<=3GB 情况下使用CMS GC

CMS GC还是不少问题的，小内存下PrallelOldGC工作更好，碎片化问题，不可预期的compact可能造成长暂停，抽发比例不好设置，多了浪费内存，少了并发失败时full serial gc，占用cpu多，碎片也影响YGC速度。