有关此问题的更新，请参阅下文
我遇到（至少对我来说是可复制的）JVM崩溃（不是OutOfMemoryError）（崩溃的应用程序是eclipse 3.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 XP 32位SP3。我有4GB的RAM。在启动应用程序之前，根据任务管理器的说法，我有2 GB的可用空间（+1 GB的系统缓存也可能被释放。）。我肯定有足够的可用RAM。
从一开始到崩溃，我使用visualvm和jconsole记录JVM内存统计信息。我获取了内存消耗统计数据，直到崩溃前的最后一刻。
统计数据显示以下分配的内存大小：
- 堆大小：751 MB（已使用248 MB）
- 非堆大小（PermGen和CodeCache）：150 MB（已使用95 MB）
- 内存管理区域的大小（Edenspace、Old gen等）：350 MB
- 线程堆栈大小：17 MB（根据oracle，由于有51个线程正在运行）
我正在使用以下参数运行应用程序（jre 6更新25，服务器vm）：
-XX:PermSize=128m
-XX:MaxPermSize=192m
-XX:ReservedCodeCacheSize=96m
-Xms500m
-Xmx1124m
问题：
- 当虚拟机和操作系统上显然有足够的内存时，为什么JVM会崩溃
使用以上设置，我认为我无法达到2GB 32位限制（1124MB+192MB+96MB+线程堆栈<2GB）。在任何其他情况下（堆分配过多），我更希望出现OutOfMemoryError，而不是JVM崩溃
谁能帮我弄清楚这里出了什么问题？
（注意：我最近从Eclipse 3.4.2升级到了Eclipse 3.6.2，从Java 5升级到了Java 6。我怀疑崩溃和这些变化之间有联系，因为我以前从未见过这些）
更新
这似乎是Java6Update25中引入的JVM错误，与新的jit编译器有关。另请参阅此博客条目。根据博客，这个错误的修复应该是下一次java6更新的一部分。与此同时，我在一次崩溃中得到了一个本机堆栈跟踪。我已经更新了上面的崩溃日志。
所提出的使用VM参数-XX:-DoEscapeAnalysis的解决方法有效（至少它显著降低了崩溃的概率）
2GB在Windows上的32位JVM上是不正确的。https://blogs.sap.com/2019/10/07/does-32-bit-or-64-bit-jvm-matter-anymore/
由于您使用的是WindowsXP，因此会遇到32位JVM的问题。
在Windows上的32位虚拟机上，最大堆为1.5GB。在没有线程的情况下，您的容量为1412MB。您是否尝试减小交换堆栈大小-Xs，以及是否尝试消除最初分配的PermSize：-XX:PermSize=128m？听起来这是一个eclipse问题，而不是内存本身的问题。
您可以在不同的机器上移动到一个新的JVM或不同的（64位）JVM吗？即使您的目标是windows XP，也没有理由在上面开发，除非迫不得已。Eclipse可以轻松地在远程机器上运行、调试和部署代码。
Eclipse的JVM可能与您在Eclipse中或使用Eclipse运行的JVM不同。Eclipse是一个内存清理器。您可以消除不必要的eclipse插件，以使用更少的eclipse内存，它附带了您可能不需要或不想要的开箱即用的东西。
尝试清空引用（以消除循环不可收集的GC对象），重新使用分配的内存，使用singleton，并配置内存使用情况，以消除不必要的对象、引用和分配。附加提示：
- 更喜欢静态内存分配，即每个VM分配一次内存，而不是到动态
- 避免在函数中创建临时对象-考虑一个reset（）方法，它可以允许重用对象
- 避免字符串突变和自动装箱类型的突变
我认为@ggb667已经确定了JVM崩溃的原因。32位Windows体系结构限制将Java应用程序的可用RAM限制为1.5GB1…而不是您推测的2GB。此外，您忽略了包括可执行文件的代码段、共享库、本地堆和"；其他事物"；。
基本上，这不是JVM错误。您只是在硬件和操作系统的限制下运行。
在某些版本的Windows中，有一种可能的解决方案是支持PAE（物理地址扩展）。根据链接，带有PAE的Windows XP为用户进程提供了高达4GB的可用地址空间。但是，对于设备驱动程序支持也有一些注意事项。
另一种可能的解决方案是减少最大堆大小，并采取其他措施来降低应用程序的内存利用率；例如在Eclipse中；打开"；工作区中的项目。
另请参阅：Windows XP 上的Java最大内存
1-不同的来源对实际限制有不同的说法，但它明显小于2GB。坦率地说，实际限制是多少并不重要。
在理想的世界里，这个问题不应该再引起任何人的实际兴趣。2020年：
- 你不应该运行Windows XP。自2014年4月以来，它已经结束了生命
- 您不应该运行Java6。自2013年4月以来，它已经结束了生命
- 如果您仍在运行Java6，那么您应该是最后一个公共补丁版本：1.6.0_45。（或者，如果您有支持合同，则可以是1.6以后的非公开版本。）
不管怎样，您都不应该在这个系统上运行Eclipse。说真的，你可以花几百美元买一台新的64位机器，它有更多的内存等，可以让你运行最新的操作系统和最新的Java版本。您应该使用那个来运行Eclipse。
如果你真的需要在一台32位的旧机器上用旧版本的Java进行Java开发（因为你买不起更新的机器），建议你使用一个简单的文本编辑器和Java 6 JDK命令行工具（以及第三方Java构建工具，如Ant、Maven、Gradle）。
最后，如果您仍在尝试运行/维护Java 6上的Java软件，那么您真的应该努力摆脱这个困境。你的生活只会越来越艰难：
- 如果Java 6软件是内部开发的，或者您有源代码，请移植它
- 如果您依赖于Java 6上的专有软件，请寻找新的供应商
- 如果管理层拒绝，就告诉他们可能需要"；关闭它"
你/你的组织早在七年前就应该处理这个问题。
我在工作中偶然发现了一个类似的问题。我们为应用程序设置了-Xmx65536M，但不断出现完全相同的错误。有趣的是，相对而言，错误总是发生在我们的应用程序实际上正在进行非常轻量级的计算的时候，因此远远没有达到这个极限。
我们在网上找到了这个问题的可能解决方案：http://www.blogsoncloud.com/jsp/techSols/java-lang-OutOfMemoryError-unable-to-create-new-native-thread.jsp，它似乎解决了我们的问题。在将-Xmx降低到50G之后，我们没有遇到这些问题。
我们仍然不清楚这种情况下实际发生了什么。
JVM有自己的限制，在达到物理或虚拟内存限制之前很久就会停止它。您需要调整的是堆大小，它与另一个-X标志一起使用。（我认为这是一个有创意的东西，比如XHeapSizeLimit，但我会稍后检查。）
我们开始了：
-Xmsn指定内存分配池的初始大小（以字节为单位）。此值必须是1024的倍数大于1MB。附加字母k或K表示千字节，或m或m以指示兆字节。默认值值为2MB。示例：
-Xms6291456 -Xms6144k -Xms6m-Xmxn指定内存分配池的最大大小（以字节为单位）。此值必须是1024的倍数大于2MB。附加字母k或K表示千字节，或m或m以指示兆字节。默认值值为64MB。示例：
-Xmx83886080 -Xmx81920k -Xmx80m