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速度。

 

最后推荐 rednaxelafx 一个300多页超长的ppt,内容很赞:http://rednaxelafx.iteye.com/blog/858009