我需要查找 Java 应用程序中的内存泄漏问题。我有一些经验，但希望能获得此方面的方法策略建议。欢迎提供任何参考和建议。
关于我们的情况：
问题：在企业级应用程序中查找泄漏问题时，哪种方法论帮助您成功？
如果没有对底层代码的一定了解，这几乎是不可能完成的任务。如果您了解底层代码，则可以更好地从堆转储中获取大量信息并进行筛选。
此外，如果不知道某个类最初存在的原因，就无法确定是否存在泄漏。
我过去几周花了大量时间来做这件事，并使用了一个迭代过程。
首先，我发现堆分析工具基本上没用。它们无法高效地分析巨大的堆。
相反，我几乎完全依赖于jmap直方图。
我想您已经熟悉这些内容，但对于那些不熟悉的人：
jmap -histo:live <pid> > histogram.out
创建一个活动堆的直方图。简单来说，它告诉您类名称以及堆中每个类的实例数量。
我定期转储堆，每5分钟一次，24小时连续不断。这对你来说可能过于详细了，但核心内容是相同的。
我在这些数据上运行了几种不同的分析。
我编写了一个脚本，用于获取两个直方图并输出它们之间的差异。因此，如果java.lang.String在第一个转储中为10，在第二个转储中为15，则我的脚本将输出“5 java.lang.String”，告诉我它增加了5。如果下降了，数字将为负数。
然后，我会获取几个这些差异，删除从一个运行到另一个运行下降的所有类，并对结果进行合并。最终，我会得到一个特定时间跨度内不断增长的类的列表。显然，这些是潜在的泄漏类的主要候选者。
但是，有些类已经保存，而其他类已被回收。这些类整体上容易上升和下降，但仍可能泄漏。因此，它们可能会从“始终上升”的类别中掉出来。
为了找到这些类，我将数据转化为时间序列并将其加载到数据库中，具体来说是Postgres。Postgres很方便，因为它提供了统计聚合函数，因此您可以在数据上进行简单的线性回归分析，并查找趋势向上的类，即使它们并不总是排在榜首。我使用regr_slope函数，寻找斜率为正的类。
我发现这个过程非常成功，而且效率很高。直方图文件并不特别大，从主机下载它们很容易。它们在生产系统上运行成本也不是特别高（它们会强制进行大型GC，并可能会阻塞VM一段时间）。我在一个具有2G Java堆的系统上运行此操作。
现在，所有这些操作只能识别潜在的泄漏类。
这就是理解类的使用方式以及它们是否应该出现的时候的作用。
例如，您可能会发现有很多Map.Entry类或其他系统类。
除非您仅仅缓存字符串，否则事实是这些系统类虽然可能是“罪犯”，但不是“问题所在”。如果您缓存了一些应用程序类，那么该类是您问题所在的更好指标。如果您没有缓存com.app.yourbean，那么将不会有与之相关联的Map.Entry。
一旦您拥有了一些类，就可以开始爬行代码库以查找实例和引用。由于您拥有自己的ORM层（无论好坏），因此至少可以轻松地查看其源代码。如果您的ORM正在缓存数据，它很可能正在缓存包装您的应用程序类的ORM类。
最后，您可以做的另一件事是一旦知道类别，就可以启动具有较小堆和较小数据集的本地服务器实例，并使用其中
可以看一下 Eclipse Memory Analyzer。这是一个很棒的工具（且自包含，不需要安装Eclipse本身），它能够快速地打开非常大的堆，并具备一些相当不错的自动检测工具。虽然后者不是完美的，但EMA提供了许多非常好的方法来浏览和查询转储中的对象，以查找可能的泄漏。
我过去使用它来帮助寻找可疑的泄漏。
^
|
s | Legend:
i | * - data point
z | -- - trend
e |
( |
b | *
y | --
t | --
e | * -- *
s | --
) | *-- *
| -- *
| -- *
--------------------------------------->
time
将您的堆转储（需要多个）转换为适合Postgres消费的格式，以从堆转储格式中获得方便：
num #instances #bytes class name
----------------------------------------------
1: 4632416 392305928 [C
2: 6509258 208296256 java.util.HashMap$Node
3: 4615599 110774376 java.lang.String
5: 16856 68812488 [B
6: 278914 67329632 [Ljava.util.HashMap$Node;
7: 1297968 62302464
...
2016.09.20 17:33:40,[C,4632416,392305928
2016.09.20 17:33:40,java.util.HashMap$Node,6509258,208296256
2016.09.20 17:33:40,java.lang.String,4615599,110774376
2016.09.20 17:33:40,[B,16856,68812488
...
使用此脚本：
# Example invocation: convert.heap.hist.to.csv.pl -f heap.2016.09.20.17.33.40.txt -dt "2016.09.20 17:33:40" >> heap.csv
my $file;
my $dt;
GetOptions (
"f=s" => \$file,
"dt=s" => \$dt
) or usage("Error in command line arguments");
open my $fh, '<', $file or die $!;
my $last=0;
my $lastRotation=0;
while(not eof($fh)) {
my $line = <$fh>;
$line =~ s/\R//g; #remove newlines
# 1: 4442084 369475664 [C
my ($instances,$size,$class) = ($line =~ /^\s*\d+:\s+(\d+)\s+(\d+)\s+([\$\[\w\.]+)\s*$/) ;
if($instances) {
print "$dt,$class,$instances,$size\n";
}
}
close($fh);
CREATE TABLE heap_histogram (
histwhen timestamp without time zone NOT NULL,
class character varying NOT NULL,
instances integer NOT NULL,
bytes integer NOT NULL
);
将数据复制到您的新表中
\COPY heap_histogram FROM 'heap.csv' WITH DELIMITER ',' CSV ;
运行倾斜查询来对字节数量进行查询：
SELECT class, REGR_SLOPE(bytes,extract(epoch from histwhen)) as slope
FROM public.heap_histogram
GROUP BY class
HAVING REGR_SLOPE(bytes,extract(epoch from histwhen)) > 0
ORDER BY slope DESC
;
解读结果：
class | slope
---------------------------+----------------------
java.util.ArrayList | 71.7993806279174
java.util.HashMap | 49.0324576155785
java.lang.String | 31.7770770326123
joe.schmoe.BusinessObject | 23.2036817108056
java.lang.ThreadLocal | 20.9013528767851
斜率是每秒增加的字节数（因为时间单位为秒）。如果使用实例代替大小，则表示每秒添加的实例数。
我其中一行创建joe.schmoe.BusinessObject的代码导致了内存泄漏。它在创建对象并将其附加到数组时未检查该对象是否已存在。其他对象也与BusinessObject一起在泄漏的代码附近创建。
我已经成功地使用IBM的Heap Analyzer。它提供了堆的几个视图，包括对象大小最大降幅、最常出现的对象以及按大小排序的对象。
如果这种情况发生在使用一周后，而且您的应用程序像您描述的那样复杂，也许每周重新启动它会更好？
我知道这并没有解决问题，但这可能是一个时间有效的解决方案。您是否有时间窗口可以进行停机维护？您能否负载均衡和故障转移一个实例，同时保持第二个实例运行？也许当内存消耗超过某个限制时（例如通过JMX或类似方式进行监控），您可以触发重新启动。
我曾经使用过jhat，这有点严厉，但它取决于你所使用的框架类型。