标签:blog http ar 使用 java sp 文件 on 问题
前些天发现: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可能造成长暂停;>8GB内存,那只能用CMS了。社区啥时候把zing的C4也给做了吧。。
最后推荐 rednaxelafx 一个300多页超长的ppt....,内容很赞:http://rednaxelafx.iteye.com/blog/858009
标签:blog http ar 使用 java sp 文件 on 问题
原文地址:http://www.cnblogs.com/lulu/p/4032356.html