有关此问题的更新,请参见下面的.。
我经历了一个JVM 崩溃(而不是OutOfMemoryError) (这个应用程序崩溃是Eclipse3.6.2)(至少对我来说是可复制的)。然而,看看坠机日志,我想知道:
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 65544 bytes for Chunk::new
# Possible reasons:
# The system is out of physical RAM or swap space
# In 32-bit mode, the process size limit was hit
# Possible solutions:
# Reduce memory load on the system
# Increase physical memory or swap space
# Check if swap backing store is full
# Use 64 bit Java on a 64 bit OS
# Decrease Java heap size (-Xmx/-Xms)
# Decrease number of Java threads
# Decrease Java thread stack sizes (-Xss)
# Set larger code cache with -XX:ReservedCodeCacheSize=
# This output file may be truncated or incomplete.
Current thread (0x531d6000): JavaThread "C2 CompilerThread1" daemon
[_thread_in_native, id=7812, stack(0x53af0000,0x53bf0000)]
Stack: [0x53af0000,0x53bf0000], sp=0x53bee860, free space=1018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [jvm.dll+0x1484aa]
V [jvm.dll+0x1434fc]
V [jvm.dll+0x5e6fc]
V [jvm.dll+0x5e993]
V [jvm.dll+0x27a571]
V [jvm.dll+0x258672]
V [jvm.dll+0x25ed93]
V [jvm.dll+0x260072]
V [jvm.dll+0x24e59a]
V [jvm.dll+0x47edd]
V [jvm.dll+0x48a6f]
V [jvm.dll+0x12dcd4]
V [jvm.dll+0x155a0c]
C [MSVCR71.dll+0xb381]
C [kernel32.dll+0xb729]
我正在使用Windows 32位SP3.我有4GB内存。在启动应用程序之前,根据任务管理器,我有2GB的空闲(+ 1GB的系统缓存,它也可能被释放)。我绝对有足够的空闲内存。
从一开始到崩溃,我使用visualvm和j控制台记录JVM内存统计信息。我获得了内存消耗的统计数据,直到坠机前的最后一刻。
统计数据显示了以下分配的内存大小:
我使用以下参数运行应用程序(jre 6 update 25,服务器vm):
-XX:PermSize=128m
-XX:MaxPermSize=192m
-XX:ReservedCodeCacheSize=96m
-Xms500m
-Xmx1124m
问题:
谁能帮我找出这里出了什么问题?
(注意:我最近升级到Eclipse3.6.2,从Eclipse3.4.2和Java 5升级到Java 6。我怀疑这些崩溃和这些更改之间存在某种联系,因为我以前从未见过这些变化)
更新
它似乎是一个JVM错误。是在Java6Update25JIT中引入的,它与新的jit编译器有关。根据博客,请参见这篇博客文章。,这个bug的修复应该是下一个java 6更新的一部分。同时,在崩溃期间,我得到了一个本机堆栈跟踪。我更新了上面的崩溃日志。
建议的解决方案,使用VM参数-XX:-DoEscapeAnalysis
工作(至少它显著降低了崩溃的可能性)
发布于 2020-02-18 16:07:19
Windows上32位JVM上的2GB是不正确的。https://blogs.sap.com/2019/10/07/does-32-bit-or-64-bit-jvm-matter-anymore/
由于您使用的是Windows,所以您只能使用32位JVM。
Windows上32位VM上的最大堆为1.5GB。从没有线程开始,您的起始时间是1412 to。您是否尝试过减少交换堆栈大小-Xss,并且是否尝试消除最初分配的PermSize:-XX:PermSize=128m?听起来这是日食问题,而不是记忆问题。
您能在不同的机器上移动到较新的JVM或不同的(64位) JVM吗?即使您是针对windows,也没有理由在其上进行开发,除非您必须这样做。Eclipse可以轻松地在远程计算机上运行、调试和部署代码。
eclipse的JVM可以与在eclipse中运行或使用eclipse运行的JVM不同。日食是一只记忆猪。您可以消除不必要的eclipse插件来使用更少的eclipse内存,它附带了一些您可能不需要或不想要的东西。
尝试删除引用(以消除循环无法收集的GC对象),重用分配的内存,使用单例,并分析您的内存使用情况,以消除不必要的对象、引用和分配。附加提示:
发布于 2012-07-10 08:33:09
我在工作中偶然发现了一个类似的问题。我们已经为我们的应用程序设置了-Xmx65536M,但是仍然得到了完全相同的错误。有趣的是,这些错误总是发生在我们的应用程序实际上正在进行相当轻量级的计算的时候,相对来说,因此远远没有达到这个极限。
我们在网上找到了一个可能的解决方案:http://www.blogsoncloud.com/jsp/techSols/java-lang-OutOfMemoryError-unable-to-create-new-native-thread.jsp,它似乎解决了我们的问题。在将-Xmx降低到50G后,我们就没有这些问题了。
在这件事上究竟发生了什么,我们还有点不清楚。
发布于 2011-06-14 13:54:50
JVM有自己的限制,在达到物理或虚拟内存限制之前很久就会停止它。需要调整的是堆大小,它带有另一个-X标志。(我认为这是像-XHeapSizeLimit这样有创意的东西,但我马上就会检查。)
我们开始吧
-Xmsn指定内存分配池的初始大小(以字节为单位)。此值必须是大于1MB的1024倍。附加字母k或K表示千字节,或m或M表示兆字节。默认值是2MB。示例: -Xms6291456 -Xms6144k -Xms6m -Xmxn指定内存分配池的最大大小(以字节为单位)。此值必须大于2MB的倍数为1024。附加字母k或K表示千字节,或m或M表示兆字节。默认值为64 is。示例: -Xmx83886080 -Xmx81920k -Xmx80m
https://stackoverflow.com/questions/6344546
复制相似问题