Jennifer软件可对Java内存追踪和监测。
Jennifer对内存漏损(Leakage)追踪- Collection/Live Object
作为诱发堆内存漏损的主要原因，可以列举特定对象的持续增加和Collection类所包含的元素的增加。为追踪使用这些对象的事务，有时会使用JVMPI(JVMTI)，但其技术特点上需要高CPU使用率。考虑到大部分内存漏损问题比起实际运营时期，更多是运营一段时间后与内存持续增加一同发生，很难用应用这些技术的工具分析内存漏损。
Java内存泄漏
2012-09-12 12:41
关注哪些类？
A. 关注自己开发的类，自己开发的代码，新开发的代码存在问题的可能性往往较大。
B. 关注自己小组开发的类。
C. 关注自己公司开发的类。
D. 关注所直接使用的第三方或框架类，如果这样的类有问题，可以通过适当的调用进行规避。
看那些指标
A. Record Count: 数据采集期间实例化而又未回收的对象数量， 如果数量大于0，需要引起注意。
2012-03-19 14:16
OOM(Out-of-Memory)是导致应用服务器/JVM不稳定的常见问题。OOM的一个重要原因是系统存在Java“内存泄漏”问题。“内存泄漏”问题是对象的生命周期问题的一种。可以理解为， 某些对象的生命周期过长，未及时清理，出现了“内存泄漏”。
2011-03-30 13:26
在了解了引起内存泄漏的一些原因后，应该尽可能地避免和发现内存泄漏。
(1)好的编码习惯。最基本的建议就是尽早释放无用对象的引用，大多数程序员在使用临时变量的时候，都是让引用变量在退出活动域后，自动设置为null。在使用这种方式时候，必须特别注意一些复杂的对象图，例如数组、列、树、图等，这些对象之间有相互引用关系较为复杂。对于这类对象，GC 回收它们一般效率较低。如果程序允许，尽早将不用的引用对象赋为null。
2011-03-30 13:14
容易引起Java内存泄漏的几大原因:
1.静态集合类
像HashMap、Vector 等静态集合类的使用最容易引起内存泄漏，因为这些静态变量的生命周期与应用程序一致，如示例1，如果该Vector 是静态的，那么它将一直存在，而其中所有的Object对象也不能被释放，因为它们也将一直被该Vector 引用着。
2 .监听器
在java 编程中，我们都需要和监听器打交道，通常一个应用当中会用到很多监听器，我们会调用一个控件的诸如addXXXListener()等方法来增加监听器，但往往在释放对象的时候却没有记住去删除这些监听器，从而增加了内存泄漏的机会。
3. 物理连接
2011-03-30 13:10
示例1
在这个例子中，循环申请Object 对象，并将所申请的对象放入一个Vector 中，如果仅仅释放引用本身，那么Vector 仍然引用该对象，所以这个对象对GC 来说是不可回收的。因此，如果对象加入到Vector 后，还必须从Vector 中删除，最简单的方法就是将Vector对象设置为null。
Vector v = new Vector(10);
for (int i = 1; i<100; i++)
{Object o = new Object();
v.add(o);
2011-03-30 12:56
在Java 中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点，首先，这些对象是可达的，即在有向图中，存在通路可以与其相连；其次，这些对象是无用的，即程序以后不会再使用这些对象。如果对象满足这两个条件，这些对象就可以判定为Java 中的内存泄漏，这些对象不会被GC 所回收，然而它却占用内存。在C++中，内存泄漏的范围更大一些。有些对象被分配了内存空间，然后却不可达，由于C++中没有GC，这些内存将永远收不回来。在Java 中，这些不可达的对象都由GC 负责回收，因此程序员不需要考虑这部分的内存泄漏。
2011-03-30 12:53
Java的一个重要优点就是通过垃圾收集器GC （Garbage Collection）自动管理内存的回收，程序员不需要通过调用函数来释放内存。因此，很多程序员认为Java 不存在内存泄漏问题，或者认为即使有内存泄漏也不是程序的责任，而是GC 或JVM的问题。其实，这种想法是不正确的，因为Java 也存在内存泄漏，但它的表现与C++不同。如果正在开发的Java 代码要全天24 小时在服务器上运行，则内存漏洞在此处的影响就比在配置实用程序中的影响要大得多，即使最小的漏洞也会导致JVM耗尽全部可用内存。