正如您从我以前的教程和案例研究中可能已经看到的那样，要确定和解决Java Heap Space OutOfMemoryError问题可能很复杂。 我从Java EE生产系统中观察到的常见问题之一是OutOfMemoryError：无法创建新的本机线程； HotSpot JVM无法进一步创建新的Java线程时引发的错误。

本文将重温此HotSpot VM错误，并为您提供建议和解决策略。

如果您不熟悉HotSpot JVM，我首先建议您从高角度查看其内部HotSpot JVM内存空间 。 为了使您了解与本机（C-Heap）内存空间有关的OutOfMemoryError问题，此知识很重要。

OutOfMemoryError：无法创建新的本机线程–这是什么？

让我们从一个基本的解释开始。 当内部JVM本机代码无法创建新的Java线程时，将引发此HotSpot JVM错误。 更准确地说，这意味着JVM本机代码无法从操作系统（Solaris，Linux，MAC，Windows等）创建新的“本机”线程。
我们可以从如下的OpenJDK 1.6和1.7实现中清楚地看到此逻辑：

不幸的是，在这一点上，您不会得到比该错误更详细的信息，没有迹象表明为什么JVM无法从OS创建新线程…

HotSpot JVM：32位还是64位？

在进行进一步分析之前，必须从Java或Java EE环境中确定的一个基本事实是，您正在使用的HotSpot VM版本是32位还是64位。
为什么这么重要？ 您将很快了解到，这个JVM问题通常与本机内存耗尽有关。 在JVM进程或OS级别。 目前，请记住：

• 理论上，一个32位JVM进程允许增长到4 GB（在某些较旧的32位Windows版本上甚至更低）。
• 对于32位JVM进程，C堆正在与Java堆和PermGen空间竞争 ，例如C堆容量= 2-4 GB – Java堆大小 （-Xms，-Xmx）– PermGen大小（-XX ：MaxPermSize）
• 从理论上讲，允许使用64位JVM进程使用大多数可用的OS虚拟内存或最多16 EB（1600万TB）

如您所见，如果您为32位JVM进程分配了较大的Java Heap（2 GB +），则本机内存空间容量将自动减少，这为JVM本机内存分配失败打开了方便之门。
对于64位JVM进程，从JVM C堆的角度来看，您主要关心的是操作系统物理，虚拟和交换内存的容量和可用性。

好的，但是本机内存如何影响Java线程的创建？

现在回到我们的主要问题。 另一个需要了解的JVM基本方面是，从JVM创建的Java线程需要来自操作系统的本机内存。 现在，您应该开始了解问题的根源…
高级线程创建过程如下：

• 从Java程序和JDK请求一个新的Java线程
• 然后，JVM本机代码尝试从OS创建一个新的本机线程
• 然后，操作系统尝试根据包括线程堆栈大小在内的属性创建一个新的本机线程。 然后，将本地内存从OS分配（保留）到Java进程本地内存空间； 假设该进程具有足够的地址空间（例如32位进程）来满足请求
• 如果32位Java进程大小耗尽了其内存地址空间，例如2 GB，3 GB或4 GB进程大小限制，则OS将拒绝任何进一步的本机线程和内存分配
• 如果操作系统的虚拟内存已耗尽（包括Solaris交换空间耗尽），则操作系统还将拒绝任何进一步的线程和本机内存分配，因为对堆栈的线程访问会生成SIGBUS错误，从而使JVM崩溃* http：//bugs.sun .com / view_bug.do？bug_id = 6302804

综上所述：

• 创建Java线程需要从OS获得可用的本机内存。 适用于32位和64位JVM进程
• 对于32位JVM，创建Java线程还需要C-Heap或进程地址空间中可用的内存

问题诊断

既然您对本地内存和JVM线程的创建有了更好的了解，现在是时候看看您的问题了。 首先，我建议您遵循以下分析方法：

1. 确定您使用的是HotSpot 32位还是64位JVM
2. 观察到问题时，请进行JVM线程转储，并确定有多少个活动线程
3. 在OOM问题复制之前和期间密切监视Java进程大小利用率
4. 在OOM问题复制之前和期间，密切监视OS虚拟内存利用率； 如果使用Solaris OS，则包括交换内存空间利用率

根据上述正确收集数据将使您可以收集适当的数据点，从而进行第一级调查。 下一步将是研究可能的问题模式，并确定哪种模式适用于您的问题案例。

问题模式1 – C堆耗尽（32位JVM）

根据我的经验，OutOfMemoryError：对于32位JVM进程，无法创建新的本机线程是很常见的。 与C堆容量相比创建太多线程时，通常会观察到此问题。 JVM线程转储分析和Java进程大小监视将使您确定是否是原因。

问题模式2 –操作系统虚拟内存耗尽（64位JVM）

在这种情况下，操作系统虚拟内存已完全耗尽。 这可能是由于一些64位JVM进程占用大量内存，例如10 GB +和/或其他占用大量内存的流氓进程。 同样，Java进程大小和OS虚拟内存监视将使您确定是否是原因。

问题模式3 –操作系统虚拟内存耗尽（32位JVM）

第三种情况不那么频繁，但仍然可以观察到。 诊断可能会稍微复杂一些，但是关键的分析点是确定哪些进程导致了OS虚拟内存的全部耗尽。 您的32位JVM进程可能是源，也可能是受害者，例如使用大多数OS虚拟内存的流氓进程，并阻止您的32位JVM进程为其线程创建过程保留更多的本机内存。

请注意，当Solaris上的OS虚拟内存或交换空间用尽时，此问题也可能表现为完全JVM崩溃（如下示例所示）。

#
# A fatal error has been detected by the Java Runtime Environment:
#
# java.lang.OutOfMemoryError: requested 32756 bytes for ChunkPool::allocate. Out of swap space?
#
#  Internal Error (allocation.cpp:166), pid=2290, tid=27
#  Error: ChunkPool::allocate
#
# JRE version: 6.0_24-b07
# Java VM: Java HotSpot(TM) Server VM (19.1-b02 mixed mode solaris-sparc )
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#---------------  T H R E A D  ---------------Current thread (0x003fa800):  JavaThread "CompilerThread1" daemon [_thread_in_native, id=27, stack(0x65380000,0x65400000)]Stack: [0x65380000,0x65400000],  sp=0x653fd758,  free space=501k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
………………

本机内存耗尽：是症状还是根本原因？

现在，您已经了解了您的问题，并且知道了要处理的问题模式。 您现在准备提供解决问题的建议……是吗？

您的工作尚未完成，请记住，此JVM OOM事件通常只是问题实际根源的“症状”。 根本原因通常更加深入，因此在向客户提供建议之前，我建议您确实进行更深入的分析。 您要做的最后一件事就是简单地解决并掩盖症状。 仅当您对根本原因和生产环境容量要求有充分了解后，才应考虑采用诸如增加操作系统物理/虚拟内存或将所有JVM进程升级到64位之类的解决方案。

下一个要回答的基本问题是，发生OutOfMemoryError时有多少个线程处于活动状态？ 根据我在Java EE生产系统中的经验，最常见的根本原因实际上是应用程序和/或Java EE容器在遇到不满意的路径（例如卡在远程IO调用中的线程）时试图在给定时间创建太多线程在这种情况下，当尝试满足传入的客户端请求时，Java EE容器可能开始创建太多线程，从而增加了C堆和本机内存分配的压力。 最重要的是，在责怪JVM之前，请执行尽职调查并确定是否要处理应用程序或Java EE容器线程调优问题是根本原因。

一旦了解并解决了根本原因（线程创建的根源），便可以调整JVM和OS内存容量，以使其更具容错能力，并更好地“生存”这些突发的线程激增方案。

建议：

• 首先执行JVM线程转储分析，并确定所有活动线程的源与已建立的基准。 确定是什么原因导致您的Java应用程序或Java EE容器在发生故障时创建了如此多的线程
• 请确保您的监视工具密切监视Java VM进程大小和OS虚拟内存。 进行完整的根本原因分析将需要此关键数据
• 不要以为您正在处理操作系统内存容量问题。 查看所有正在运行的进程，并确定您的JVM进程实际上是问题的根源还是其他消耗所有虚拟内存的进程的受害者
• 重新访问Java EE容器线程配置和JVM线程堆栈大小。 确定是否允许Java EE容器创建比JVM进程和/或OS可以处理的线程更多的线程
• 确定您的32位JVM的Java堆大小是否太大，从而阻止JVM创建足够的线程来满足客户端请求。 在这种情况下，您将不得不考虑减小Java堆大小（如果可能），垂直扩展或升级到64位JVM。

救援能力规划分析

正如您从我以前关于Java EE企业性能问题的十大原因的文章中可能已经看到的那样，缺乏容量规划分析通常是问题的根源。 任何全面的负载和性能测试活动都应正确确定生产环境的Java EE容器线程，JVM和OS本机内存需求； 包括“不满意”路径的影响测量。 这种方法将使您的生产环境避免此类问题，从长远来看，可导致更好的系统可伸缩性和稳定性。

别忘了分享！

参考： OutOfMemoryError：无法创建新的本机线程– Java EE支持模式和Java教程博客上的JCG合作伙伴 Pierre-Hugues Charbonneau 揭开了神秘的面纱 。