Java 堆转储错误 - 元数据似乎不是多态的
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/33733445/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Java Heap Dump error - Metadata does not appear to be polymorphic
提问by RobAu
I get this Stacktrace when trying to take a heap dump from a running Java process. What causes this and what do I have to do to make a proper heap dump?
尝试从正在运行的 Java 进程中获取堆转储时，我得到了这个 Stacktrace。是什么导致了这种情况，我该怎么做才能进行适当的堆转储？
Dumping heap to dump.bin ...
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at sun.tools.jmap.JMap.runTool(JMap.java:201)
at sun.tools.jmap.JMap.main(JMap.java:130)
Caused by: java.lang.InternalError: Metadata does not appear to be polymorphic
at sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:278)
at sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:102)
at sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:68)
at sun.jvm.hotspot.memory.DictionaryEntry.klass(DictionaryEntry.java:71)
at sun.jvm.hotspot.memory.Dictionary.classesDo(Dictionary.java:66)
at sun.jvm.hotspot.memory.SystemDictionary.classesDo(SystemDictionary.java:190)
at sun.jvm.hotspot.memory.SystemDictionary.allClassesDo(SystemDictionary.java:183)
at sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeClasses(HeapHprofBinWriter.java:942)
at sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:427)
at sun.jvm.hotspot.tools.HeapDumper.run(HeapDumper.java:62)
at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260)
at sun.jvm.hotspot.tools.Tool.start(Tool.java:223)
at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
at sun.jvm.hotspot.tools.HeapDumper.main(HeapDumper.java:83)
... 6 more
Environment: CentOS 64 bit, Java OpenJDK Runtime Environment (build 1.8.0_31-b13) OpenJDK 64-Bit Server VM (build 25.31-b07, mixed mode)
环境：CentOS 64 位，Java OpenJDK 运行时环境（构建 1.8.0_31-b13） OpenJDK 64 位服务器 VM（构建 25.31-b07，混合模式）
Usign psto see the java version that is used:
使用签名ps查看使用的java版本：
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.31-1.b13.el6_6.x86_64/jre/bin/java
My first try was:
我的第一次尝试是：
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.31-1.b13.el6_6.x86_64/bin/jmap -dump:format=b,file=dump.bin 14984
That got me :
这让我：
14984: Unable to open socket file: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding
So I ran with the -Foption
所以我-F选择了
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.31-1.b13.el6_6.x86_64/bin/jmap -F -dump:format=b,file=dump.bin 14984
回答by RobAu
Ok, I found it.
好的，我找到了。
I was running the jmapcommand as root, but I had to run as the user that started the java process.
我以jmap身份运行命令root，但我必须以启动 java 进程的用户身份运行。
In my case:
就我而言：
sudo -u robau ./jmap -dump:format=b,file=/tmp/dump.bin 14984
Seems to be related to this JDK bug: https://bugs.openjdk.java.net/browse/JDK-8075773
似乎与这个 JDK 错误有关：https: //bugs.openjdk.java.net/browse/JDK-8075773
回答by Big Pumpkin
I ran into the same issue with trying to run jmap on an AWS ElasticBeanstalk instance. The command that fixed it was
我在尝试在 AWS ElasticBeanstalk 实例上运行 jmap 时遇到了同样的问题。修复它的命令是
sudo debuginfo-install java-1.8.0-openjdk-devel
sudo debuginfo-install java-1.8.0-openjdk-devel
BTW, jmap was installed on the AWS ElasticBeanstalk instance with command
顺便说一句，jmap 是通过命令安装在 AWS ElasticBeanstalk 实例上的
sudo yum install java-1.8.0-openjdk-devel-1.8.0.91-0.b14.10.amzn1.x86_64
sudo yum install java-1.8.0-openjdk-devel-1.8.0.91-0.b14.10.amzn1.x86_64
回答by PeteyPabPro
I had this issue on CentOS even when running as the user that started the process. What solved it for me was installing the debuginfo package corresponding to the package supplying the jmap utility.
即使以启动进程的用户身份运行，我在 CentOS 上也遇到了这个问题。为我解决的是安装与提供 jmap 实用程序的包相对应的 debuginfo 包。
To install the debuginfo package, see this answer(substituting your java package for glibc). It requires getting/using the debuginfo-install utility, and making sure the CentOS-Debuginfo.repois set up correctly and enabled.
要安装 debuginfo 包，请参阅此答案（用您的 java 包替换 glibc）。它需要获取/使用 debuginfo-install 实用程序，并确保正确设置并启用CentOS-Debuginfo.repo。
回答by Zeki
On Ubuntu, I resolved this issue by installing the openjdk-dbg package:
在 Ubuntu 上，我通过安装 openjdk-dbg 包解决了这个问题：
sudo apt-get install openjdk-8-dbg
I now suspect that this resolved my issue indirectly by upgrading the jdk to a version that corrected the bug. You might be able to resolve this issue with:
我现在怀疑这通过将 jdk 升级到更正错误的版本间接解决了我的问题。您或许可以通过以下方式解决此问题：
sudo apt-get install openjdk-8
Note:After java is upgraded, you must restart the java process in order to get a proper dump. If you don't, you will get something like this:
注意：Java 升级后，您必须重新启动 java 进程才能获得正确的转储。如果你不这样做，你会得到这样的东西：
Attaching to process ID 21957, please wait...
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.tools.jmap.JMap.runTool(JMap.java:201)
at sun.tools.jmap.JMap.main(JMap.java:130)
Caused by: sun.jvm.hotspot.debugger.UnmappedAddressException: 7f21453c9bf8
at sun.jvm.hotspot.debugger.PageCache.checkPage(PageCache.java:208)
at sun.jvm.hotspot.debugger.PageCache.getData(PageCache.java:63)
at sun.jvm.hotspot.debugger.DebuggerBase.readBytes(DebuggerBase.java:225)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.readCInteger(LinuxDebuggerLocal.java:498)
at sun.jvm.hotspot.debugger.linux.LinuxAddress.getCIntegerAt(LinuxAddress.java:69)
at sun.jvm.hotspot.HotSpotTypeDataBase.getLongValueFromProcess(HotSpotTypeDataBase.java:604)
at sun.jvm.hotspot.HotSpotTypeDataBase.readVMTypes(HotSpotTypeDataBase.java:164)
at sun.jvm.hotspot.HotSpotTypeDataBase.<init>(HotSpotTypeDataBase.java:89)
at sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:395)
at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:305)
at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:140)
at sun.jvm.hotspot.tools.Tool.start(Tool.java:185)
at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
at sun.jvm.hotspot.tools.HeapDumper.main(HeapDumper.java:83)
... 6 more
