我想分析码头的堆外内存使用情况。
因此,我使用gperftools并将env添加到jetty.sh中:

export LD_PRELOAD=/usr/local/lib/libtcmalloc.so
# export HEAPPROFILE=/home/cccccc/perftools/mybin


工作正常

[root@xxx ~]# lsof -n | grep tcmalloc
java      23200           root  mem       REG              253,1    2350880     667001 /usr/local/lib/libtcmalloc.so.4.5.3
java      23200 23203     root  mem       REG              253,1    2350880     667001 /usr/local/lib/libtcmalloc.so.4.5.3
java      23200 23204     root  mem       REG              253,1    2350880     667001 /usr/local/lib/libtcmalloc.so.4.5.3
java      23200 23205     root  mem       REG              253,1    2350880     667001 /usr/local/lib/libtcmalloc.so.4.5.3


但是当我注释掉HEAPPROFILE并尝试service jetty restart(start)时。
登录后

Starting tracking the heap
Starting tracking the heap
Starting tracking the heap
Starting tracking the heap
Starting tracking the heap
Starting tracking the heap
Starting tracking the heap
Starting tracking the heap
Starting tracking the heap
Starting tracking the heap
Starting tracking the heap
Starting tracking the heap
Starting tracking the heap
Starting tracking the heap
Starting tracking the heap
Starting tracking the heap
Dumping heap profile to /home/cccccc/perftools/mybin.0001.heap (Exiting, 0 bytes in use)
Starting tracking the heap
Starting tracking the heap
Starting tracking the heap
Starting tracking the heap
Starting Jetty: Starting tracking the heap
Starting tracking the heap
Starting tracking the heap
ok Thu Sep 20 20:33:36 CST 2018


它退出了。
并检查错误日志,我发现这是一个“ libunwind”错误。

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f882ad93dd4, pid=18147, tid=0x00007f882949a700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_122-b03) (build 1.8.0_122-ea-b03)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.122-b03 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libunwind.so.8+0x2dd4]  access_mem+0x24


(完整内容:https://drive.google.com/open?id=1JB3R27Udpdid3FMgnoWQPr516gZsSfc3

距离我的范围太远了。
我将gperftools-2.7libunwind-1.2.1一起使用(在使用libunwind-0.99-BETA相同的结果之前)。
可能很难解决。环境因素太多。

最佳答案

这个问题几乎可以肯定是由于libunwind试图处理由JVM(热点等)动态生成的代码的堆栈帧。我想即使“口译员”也不是真正的古典口译员。

我认为最好的选择是切换到基于帧指针的展开(将TCMALLOC_STACKTRACE_METHOD = x86作为环境变量传递)。并且您需要使用-XX:+ PreserveFramePointer运行JVM(请参见https://medium.com/netflix-techblog/java-in-flames-e763b3d32166

10-08 15:10