使用JProfilerをメモリ分析
動作環境：
Tomcat6、JDK6、JProfiler8
メモリー・リーク現象：
1.ではなく、落下のメモリを見つけ、サーバーでバッチ操作にいくつかの時間を実行します。でもGC後、メモリを完全に解放することはできません。
2.再起動Tomcatサーバーのメモリが解放されることはありませんない限りは、これらのアクションが使用可能なメモリーなしになります繰り返し、Tomcatが死亡しました。
メモリリークのための使用チェックがJProfilerをステップ：
1.初期化テスト環境：
切り替え - タブは、あなたが他のバージョンが異なる位置でもよいJProfilerを現在のTomcat内のオブジェクト、注意を見ることができる「ライブ・メモリー>すべてのオブジェクト」。
操作を実行する前に、無効をクリーンアップするためにF4、実行「ファイル名を指定して実行GC」、オブジェクトのJVMガベージコレクションする必要があります。メモリの成長の比較を容易にするために、あなたは右クリックすることができます--->「マークの現在」、
参照として現在のメモリ使用量に、オブジェクトの変更および変化率の表示「差」の欄をクリックし、カラムリスト番号
2.メモリーレコード：
録音を開始するには、「スタート録音」ボタンをクリックしてください。このステップの実装の主な目的は、「ヒープウォーカー」は、以下の監視間隔を設定することで、あなたは時間がかかり、すべてのメモリ、JVMの仮想マシンを分析する言葉「ヒープウォーカー」を記録していないとメモリリークの正確な原因を見つけることができない場合。
操作はGCを行っ実行3.。
使用压力工具访问被测应用，执行完之后再次F4进行GC----这样是为了消除可以回收的对象。执行内存回收后，仍然存在于内存中的对象有可能是泄漏的对象。如下图instance count中红色的部门为不能回收的对象，difference列列出了增加的对象数量和增。以String为例，在该操作中增加了31751个对象增幅达到了14%，随后会在HeapWalker中观察这些对象，分析哪些对象是泄漏的。一般引起泄漏的对象包括：String、char[]、HashMap、Concurrenthashmap等，这类对象需要重点关注下；
4. 关闭内存记录：
点击“Stop Recordings”关闭内存记录，告诉jProfiler把这段记录作为分析对象；
5. 找到增加迅速的对象类型，打开HeapWalker：
在视图中找到增长快速的对象类型，本例Concurrenthashmap的增长速度很快。在memory视图中找到Concurrenthashmap---点右键----选择“Show Selectiion In Heap Walker”，切换到HeapWarker 视图；切换前会弹出选项页面，注意一定要选择“Select recorded objects”，这样Heap Walker会在刚刚的那段记录中进行分析；否则，会分析tomcat的所有内存对象，这样既耗时又不准确；
6. 在HeapWalker中，找到泄漏的对象；
HeapWarker 会分析内存中的所有对象，包括对象的引用、创建、大小和数量；
HeapWarker视图下方可以进行页面切换：
通过切换到References页签，可以看到这个类的具体对象实例。
为了在这些内存对象中，找到泄漏的对象（应该被回收），可以在该对象上点击右键，选择“Use Selected Instances”缩小对象范围；
单击OK按钮
7. 通过引用分析该对象：
在References引用页签中，可以看到该对象的的引用关系，可以切换incoming/outcoming，显示引用的类型：
incoming 表示显示这个对象被谁引用；
outcoming 表示显示这个对象引用的其他对象；
选择“Show In Graph”将引用关系使用图形方式展现；
选中该对象，点击“Show Paths To GC Root”，会找到引用的根节点；
在上图中，我们可以发现，这个HashMap Segment对象最终的引用是在ConcurrentHashMap和ReentranLock对象中；
8. 通过创建分析该对象：
如果第7步还不能定位内存泄露的地方，我们可以尝试使用Allocations页签，该页签显示对象是如何创建出来的；
我们可以从创建方法开始检查，检查所有用到该对象的地方，直到找到泄漏位置；
持续学习、持续收获才能带来持续的满足和快乐！