《java问题定位技术-内存专题》由会员分享，可在线阅读，更多相关《java问题定位技术-内存专题（15页珍藏版）》请在金锄头文库上搜索。
1、JAVA问题定位技术-内存专题,Central R&D LMT（iSAP） 刘铁00104163,Page 2,垃圾回收机制,提纲,JAVA内存泄露,JVM Architecture,Page 3,JVM架构-JVM系统结构,两个子系统 Class Loader Execution Engine 两个组件 Runtime data area Native interface,Page 4,JVM架构-内存区结构,年轻代 Eden - Survior From Suivior to 年老代 存放年轻代存活的对象 持久代 存放静态文件,Java类，方法等,Page 5,垃圾回收机制-两种GC,Sc
2、avenge GC 普通GC，这种gc可以很容易的得到。一般情况下，当新对象生成，并且在Eden申请空间失败时，就会触发Scavenge GC，堆Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor区。然后整理Survivor的两个区。 Full GC 对整个堆进行整理，包括Young、Tenured和Perm。Full GC比Scavenge GC要慢，因此应该尽可能减少Full GC。有如下原因可能导致Full GC： Tenured被写满 Perm域被写满 System.gc()被显示调用 上一次GC之后Heap的各域分配策略动态变化,Page 6,垃圾回收-
3、JVM参数,初始堆大小最大堆大小 JAVA_OPTS=%JAVA_OPTS% -server -Xms512m -Xmx800m 问题：是否要把Xms和Xmx设置为一样？ IBM JDK采用的是标记（mark）-扫描（sweep）-标记-扫描-紧凑排列（compact），如果还不能提供足够的空间，扩展堆（expasion）。依次循环，直到达到最大堆大小。每次扩展前，那些长存的对象就被调整到堆的底部，所以每次扩展后再此调整的内存量就会变得越来越小。如果把Xms设置成和Xmx一样，那么扫描和紧凑排列这么一个充满内存碎片的大堆的开销将大大高于从小扩展堆的开销。因此如果使用的是IBM JDK这两个参数
4、不宜设置为一样。 Oracle(SUN) JDK采用的是分代回收的策略，所以就没有这种情况，反而会受益于堆大小一致。IBMJDK设置回收策略设置为分代回收-Xgcpolicy:gencon，就应该把最小堆最大堆设置成一样。 Notes：IBM JDK缺省的GC策略是针对吞吐量优化的，对响应时间要求高的应用不宜使用这种GC策略 打开GC日志 JAVA_OPTS=%JAVA_OPTS% -verbose:gc -Xloggc:gcfile.txt,Page 7,垃圾回收-GC日志分析(OracleSUN JDK),GC日志 Full GC 337528K-168033K(337532K), 1.4
5、347402 secs Full GC 339720K-170863K(339836K), 1.6085845 secs Full GC 358036K-181013K(358164K), 1.8888045 secs Full GC 360699K-181703K(360700K), 1.9296013 secs,这里表示Full GC，定位内存泄露时我们之关注Full,这个值表示之前内存大小为，之后大小为，大概一半的垃圾被回收了,表示当前JVM heap的总大小,GC花费的时间，FullGC的同时会耗费大量地CPU时间，这个时间不宜过大也不宜过于频繁,Page 8,垃圾回收-GC日志分析(
6、IBM JDK),Page 9,内存泄露-什么对象可以回收？,方法结束时，给某对象赋空值 public SelectAction() favouriteLanguages.add(“test“); /add your codes favouriteLanguages=null; 对象自动出了作用域 一个变量或对象只在一个方法内有效或者有很明确的作用范围。程序执行完了，那个方法，或者作用域就无效了 显式的告诉虚拟机对象不再被使用了 内存孤岛,Page 10,内存泄露- 获取heapDump,Oracle(SUN) JDK： 系统启动加入参数：XX:+HeapDumpOnOutOfMemoryEr
7、ror 设置示例: set JAVA_OPTS=%JAVA_OPTS% -server -Xms512m -Xmx800m -XX:PermSize=64M -XX:MaxPermSize=128m -Djava.awt.headless=true -XX:+HeapDumpOnOutOfMemoryError 注：如增加HeapDumpOnCtrlBreak Option就可以通过ctrl+break或收到SIGQUIT生成heapdump文件 设置示例: set JAVA_OPTS=%JAVA_OPTS% -server -Xms512m -Xmx800m -XX:PermSize=64M
8、 -XX:MaxPermSize=128m -Djava.awt.headless=true -XX:+HeapDumpOnOutOfMemoryError -XX:+HeapDumpOnCtrlBreak IBM JDK： 环境变量需要设置如下参数 export IBM_HEAPDUMP=true export IBM_HEAP_DUMP=true export IBM_HEAPDUMP_OUTOFMEMORY=true 如何打开HeapDump？ 大多数情况下JVM Crash之后生成的HeapDump非常大，1G-4G不等，打开HeapDump要求机器性能较好，并且机器的内存大小不能小于
9、HeapDump文件的大小，使用IBM HeapAnalyzer分析时分配的内存最好为HeapDump文件的1.5-2倍。另外如果heapDump大于2G，必须使用64位的机器打开，32位最大只能分配2G的内存，示例： isap-1-14:/ha36 java -jar -Xmx1500m ha36.jar 64位机器确定方法：CPU，JDK，OS均为为64位才能确定是64位机器,Page 11,内存泄露- 分析heapDump文件,Page 12,内存泄露-借助JProfiler在线分析内存泄露,如何启用JProfiler？ Linux:catalina.sh中添加 JAVA_OPTS=“%
10、JAVA_OPT% -agentlib:jprofilerti=port=8849 -Xbootclasspath/a:/home/csp01/jprofiler5/bin/agent.jar“ Windows下：run.bat/Catalina.bat加入： JVM 1.5.0以上： call “%JAVA_HOME%binjava“ %JAVA_OPT% -agentlib:jprofilerti=port=8849 “- Xbootclasspath/a:D:Program Filesjprofiler4binagent.jar“ JVM 1.4.2以下： call “%JAVA_HOM
11、E%binjava“ %JAVA_OPT% -Xrunjprofiler:port=8849 “- Xbootclasspath/a:D:Program Filesjprofiler4binagent.jar“ 使用JProfiler要注意什么？ Windows下：run.bat/Catalina.bat加入：JProfiler本身需要消耗很大的本地内存，挂上JProfiler的JVM进行自身对象信息收集也需要消耗大量内存，因此要非常注意Xmx值设置的大小，太小太大都会导致JVM Core Dump JProfiler进行对象信息收集非常消耗CPU，通过压力测试重现问题时压力一定要低，否则会出
12、现很多其他错误，干扰分析结果 挂上JProfiler的JVM非常容易Core Dump，最好打开-verbose:gc,随时观察JVM内存使用情况，内存消耗比较大时应减小甚至停止压力测试，立即进行分析,Page 13,内存泄露-借助JProfiler在线分析内存泄露,相对于mark（A时刻作标记，以A时刻为参照）时刻，又有多少实例被创建。系统运行稳定后，如果classA是正常的且被正常引用的，他的数目在 garbage cellector后会全部回收，值为0。有一种情况，如果classA是required（必须的），就是应用程序正常运行过程中classA的数目就 应该增加，但是增加到一定数目B（此数目或者是设定的，或者是可预知的，比方一个网站的用户注册量，我们几乎可以估计到他的数目不会超过某一个数值C）就 不会增加了。这个difference值在garbage collector后就不会降低。如果一个类ClassB不是required，用完会马上释放的（这个要根据业务来判断，需要熟悉业务代码者判断），但 是他的数目在garbage collector后又没有释放，这个就是有问题的。,当前运行的服务器上所有类的名字,对应的类当前创建的实例总数目,当前类的所有实例占的内存总量,Page 14,内存泄露-典型案例,见附件,Thank You,,
