本文基于 Java 15html
StackOverflowError 与 OutOfMemoryError 是两个老生常谈的 Java 错误。Java 中的虚拟机错误 VirtualMachineError 包括如下四种：java
咱们比较关心的就是 StackOverflowError 与 OutOfMemoryError，剩下的 InternalError 通常是内部使用错误，UnknownError 是虚拟机发生未知异常，这两种咱们这里不讨论。react
虚拟机规范中的 StackOverflowError 与 OutOfMemoryError
参考 Java 虚拟机规范官方文档：Run-Time Data Areas，能够知道，在以下状况下，会抛出这两种错误：linux
- 当某次线程运行计算时，须要占用的 Java 虚拟机栈（Java Virtual Machine Stack）大小，也就是 Java 线程栈大小，超过规定大小时，抛出 StackOverflowError
- 若是 Java 虚拟机栈大小能够动态扩容，发生扩容时发现内存不足，或者新建Java 虚拟机栈时发现内存不足，抛出 OutOfMemoryError
- 当所须要的堆（heap）内存大小不足时，抛出 OutOfMemoryError
- 当方法区（Method Area）大小不够分配时，抛出 OutOfMemoryError
- 当建立一个类或者接口时，运行时常量区剩余大小不够时，抛出 OutOfMemoryError
- 本地方法栈（Native Method Stack）大小不足时，抛出 StackOverflowError
- 本地方法栈（Native Method Stack）扩容时发现内存不足，或者新建本地方法栈发现内存不足，抛出 OutOfMemoryError
Hotspot JVM 的实现
为了进一步搞清楚 StackOverflowError 与 OutOfMemoryError，咱们来看具体实现。通常的 JVM 采用的都是官网的 HotSpot JVM，咱们这里就用 Hotspot JVM 的实现来讲明。git
JVM 内存包括什么
咱们通常经过两个工具 pmap 还有 jcmd 中的 VM.native_memory 命令去查看 Java 进程内存占用，因为 pmap 命令有点复杂并且不少内存映射是 anon 的，这里采用 jcmd 中的 VM.native_memory 命令，去看一下 JVM 内存的每一部分。须要指出的一点是，github
若是想了解详细的 Native Memory Tracking，请参考个人另外一篇文章JVM相关 - JVM 内存占用与分析vim
Native Memory Tracking:
Total: reserved=6308603KB, committed=4822083KB
- Java Heap (reserved=4194304KB, committed=4194304KB)
(mmap: reserved=4194304KB, committed=4194304KB)
- Class (reserved=1161041KB, committed=126673KB)
(classes #21662)
( instance classes #20542, array classes #1120)
(malloc=3921KB #64030)
(mmap: reserved=1157120KB, committed=122752KB)
( Metadata: )
( reserved=108544KB, committed=107520KB)
( used=105411KB)
( free=2109KB)
( waste=0KB =0.00%)
( Class space:)
( reserved=1048576KB, committed=15232KB)
( used=13918KB)
( free=1314KB)
( waste=0KB =0.00%)
- Thread (reserved=355251KB, committed=86023KB)
(thread #673)
(stack: reserved=353372KB, committed=84144KB)
(malloc=1090KB #4039)
(arena=789KB #1344)
- Code (reserved=252395KB, committed=69471KB)
(malloc=4707KB #17917)
(mmap: reserved=247688KB, committed=64764KB)
- GC (reserved=199635KB, committed=199635KB)
(malloc=11079KB #29639)
(mmap: reserved=188556KB, committed=188556KB)
- Compiler (reserved=2605KB, committed=2605KB)
(malloc=2474KB #2357)
(arena=131KB #5)
- Internal (reserved=3643KB, committed=3643KB)
(malloc=3611KB #8683)
(mmap: reserved=32KB, committed=32KB)
- Other (reserved=67891KB, committed=67891KB)
(malloc=67891KB #2859)
- Symbol (reserved=26220KB, committed=26220KB)
(malloc=22664KB #292684)
(arena=3556KB #1)
- Native Memory Tracking (reserved=7616KB, committed=7616KB)
(malloc=585KB #8238)
(tracking overhead=7031KB)
- Arena Chunk (reserved=10911KB, committed=10911KB)
(malloc=10911KB)
- Tracing (reserved=25937KB, committed=25937KB)
(malloc=25937KB #8666)
- Logging (reserved=5KB, committed=5KB)
(malloc=5KB #196)
- Arguments (reserved=18KB, committed=18KB)
(malloc=18KB #486)
- Module (reserved=532KB, committed=532KB)
(malloc=532KB #3579)
- Synchronizer (reserved=591KB, committed=591KB)
(malloc=591KB #4777)
- Safepoint (reserved=8KB, committed=8KB)
(mmap: reserved=8KB, committed=8KB)
这里的 mmap，malloc 是两种不一样的内存申请分配方式，例如：windows
Internal (reserved=3643KB, committed=3643KB)
(malloc=3611KB #8683)
(mmap: reserved=32KB, committed=32KB)
表明 Internal 一共占用 3643KB，其中3611KB是经过 malloc 方式，32KB 是经过 mmap 方式。 arena 是经过 malloc 方式分配的内存可是代码执行完并不释放，放入 arena chunk 中以后还会继续使用，参考：MallocInternals数组
能够看出，Java 进程内存包括：服务器
- Java Heap: 堆内存，即
-Xmx限制的最大堆大小的内存。 - Class：加载的类与方法信息，其实就是 metaspace，包含两部分： 一是 metadata，被
-XX:MaxMetaspaceSize限制最大大小，另外是 class space，被-XX:CompressedClassSpaceSize限制最大大小 - Thread：线程与线程栈占用内存，每一个线程栈占用大小受
-Xss限制，可是总大小没有限制。 - Code：JIT 即时编译后（C1 C2 编译器优化）的代码占用内存，受
-XX:ReservedCodeCacheSize限制 - GC：垃圾回收占用内存，例如垃圾回收须要的 CardTable，标记数，区域划分记录，还有标记 GC Root 等等，都须要内存。这个不受限制，通常不会很大的。
- Compiler：C1 C2 编译器自己的代码和标记占用的内存，这个不受限制，通常不会很大的
- Internal：命令行解析，JVMTI 使用的内存，这个不受限制，通常不会很大的
- Symbol: 常量池占用的大小，字符串常量池受
-XX:StringTableSize个数限制，总内存大小不受限制 - Native Memory Tracking：内存采集自己占用的内存大小，若是没有打开采集（那就看不到这个了，哈哈），就不会占用，这个不受限制，通常不会很大的
- Arena Chunk：全部经过 arena 方式分配的内存，这个不受限制，通常不会很大的
- Tracing：全部采集占用的内存，若是开启了 JFR 则主要是 JFR 占用的内存。这个不受限制，通常不会很大的
- Logging，Arguments，Module，Synchronizer，Safepoint，Other，这些通常咱们不会关心。
除了 Native Memory Tracking 记录的内存使用，还有两种内存 Native Memory Tracking 没有记录，那就是：
- Direct Buffer：直接内存，请参考：JDK核心JAVA源码解析（4） - Java 堆外内存、零拷贝、直接内存以及针对于NIO中的FileChannel的思考
- MMap Buffer：文件映射内存，请参考：JDK核心JAVA源码解析（5） - JAVA File MMAP原理解析
各类 StackOverflowError 与 OutOfMemoryError 场景以及定位方式
1. StackOverflowError
调用栈过深，致使线程栈占用大小超过-Xss（或者是-XX:ThreadStackSize）的限制，若是没指定-Xss，则根据不一样系统肯定默认最大大小。
肯定默认大小的代码请参考：
- windows：os_windows.cpp
- linux：os_linux.cpp
总结起来就是，32 位的系统通常是 512k，64 位的是 1024k
通常报这个错都是由于递归死循环，或者调用栈真的太深而线程栈大小不足，好比那种回调背压模型的框架，netty + reactor 这种，通常线程栈须要调大一点。
2. OutOfMemoryError: Java heap space
堆内存不够用，没法分配更多内存，就会抛出这个异常。通常这种状况发生后，须要查看 heap dump，线上应用通常加上-XX: +HeapDumpOnOutOfMemoryError在OutOfMemoryError发生的时候，进行 heap dump，以后进行分析。
heap dump 查看工具通常经过 Memory Analyzer (MAT)
3. OutOfMemoryError: unable to create native thread
这个在建立太多的线程，超过系统配置的极限。如Linux默认容许单个进程能够建立的线程数是1024个。
通常报这个错首先考虑不要建立那么多线程，线程池化并池子尽可能同业务复用。若是实在要建立那么多线程，则考虑修改服务器配置：
//查看限制个数 ulimit -u //编辑修改 vim /etc/security/limits.d/90-nproc.conf
4. OutOfMemoryError: GC Overhead limit exceeded
默认状况下，并非等堆内存耗尽，才会报 OutOfMemoryError，而是若是 JVM 以为 GC 效率不高，也会报这个错误。
那么怎么评价 GC 效率不高呢？来看下源码： 呢？来看下源码gcOverheadChecker.cpp：
void GCOverheadChecker::check_gc_overhead_limit(GCOverheadTester* time_overhead,
GCOverheadTester* space_overhead,
bool is_full_gc,
GCCause::Cause gc_cause,
SoftRefPolicy* soft_ref_policy) {
// 忽略显式gc命令，好比System.gc()，或者经过JVMTI命令的gc，或者经过jcmd命令的gc
if (GCCause::is_user_requested_gc(gc_cause) ||
GCCause::is_serviceability_requested_gc(gc_cause)) {
return;
}
bool print_gc_overhead_limit_would_be_exceeded = false;
if (is_full_gc) {
//若是gc时间过长，而且gc回收的空间仍是很少
//gc时间占用98%以上为gc时间过长，能够经过 -XX:GCTimeLimit= 配置，参考gc_globals.hpp: GCTimeLimit
//回收空间小于2%为gc回收空间很少，能够经过 -XX:GCHeapFreeLimit= 配置，参考gc_globals.hpp: GCHeapFreeLimit
if (time_overhead->is_exceeded() && space_overhead->is_exceeded()) {
_gc_overhead_limit_count++;
//若是UseGCOverheadLimit这个状态位为开启
//默认状况下，是开启的，能够经过启动参数-XX:-UseGCOverheadLimit关闭，参考：gc_globals.hpp: UseGCOverheadLimit
if (UseGCOverheadLimit) {
//若是超过规定次数，这个次数默认不可配置，必须开启develop编译jdk才能配置，参考gc_globals.hpp: GCOverheadLimitThreshold
if (_gc_overhead_limit_count >= GCOverheadLimitThreshold){
//设置状态位，准备抛出OOM
set_gc_overhead_limit_exceeded(true);
//清空计数
reset_gc_overhead_limit_count();
} else {
//若是还没到达次数，可是也快到达的时候，清空全部的软引用
bool near_limit = gc_overhead_limit_near();
if (near_limit) {
soft_ref_policy->set_should_clear_all_soft_refs(true);
log_trace(gc, ergo)("Nearing GC overhead limit, will be clearing all SoftReference");
}
}
}
//须要打印日志，提示GC效率不高
print_gc_overhead_limit_would_be_exceeded = true;
} else {
// Did not exceed overhead limits
reset_gc_overhead_limit_count();
}
}
if (UseGCOverheadLimit) {
if (gc_overhead_limit_exceeded()) {
log_trace(gc, ergo)("GC is exceeding overhead limit of " UINTX_FORMAT "%%", GCTimeLimit);
reset_gc_overhead_limit_count();
} else if (print_gc_overhead_limit_would_be_exceeded) {
assert(_gc_overhead_limit_count > 0, "Should not be printing");
log_trace(gc, ergo)("GC would exceed overhead limit of " UINTX_FORMAT "%% %d consecutive time(s)",
GCTimeLimit, _gc_overhead_limit_count);
}
}
}
默认配置：gc_globals.hpp
product(bool, UseGCOverheadLimit, true, \
"Use policy to limit of proportion of time spent in GC " \
"before an OutOfMemory error is thrown") \
\
product(uintx, GCTimeLimit, 98, \
"Limit of the proportion of time spent in GC before " \
"an OutOfMemoryError is thrown (used with GCHeapFreeLimit)") \
range(0, 100) \
\
product(uintx, GCHeapFreeLimit, 2, \
"Minimum percentage of free space after a full GC before an " \
"OutOfMemoryError is thrown (used with GCTimeLimit)") \
range(0, 100) \
\
develop(uintx, GCOverheadLimitThreshold, 5, \
"Number of consecutive collections before gc time limit fires") \
range(1, max_uintx)
能够总结出：默认状况下，启用了 UseGCOverheadLimit，连续 5 次，碰到 GC 时间占比超过 98%，GC 回收的内存不足 2% 时，会抛出这个异常。
5. OutOfMemoryError: direct memory
这个是向系统申请直接内存时，若是系统可用内存不足，就会抛出这个异常，对应的源代码Bits.java：
static void reserveMemory(long size, int cap) {
synchronized (Bits.class) {
if (!memoryLimitSet && VM.isBooted()) {
maxMemory = VM.maxDirectMemory();
memoryLimitSet = true;
}
// -XX:MaxDirectMemorySize limits the total capacity rather than the
// actual memory usage, which will differ when buffers are page
// aligned.
if (cap <= maxMemory - totalCapacity) {
reservedMemory += size;
totalCapacity += cap;
count++;
return;
}
}
System.gc();
try {
Thread.sleep(100);
} catch (InterruptedException x) {
// Restore interrupt status
Thread.currentThread().interrupt();
}
synchronized (Bits.class) {
if (totalCapacity + cap > maxMemory)
throw new OutOfMemoryError("Direct buffer memory");
reservedMemory += size;
totalCapacity += cap;
count++;
}
}
在 DirectByteBuffer 中，首先向 Bits 类申请额度，Bits 类有一个全局的 totalCapacity 变量，记录着所有 DirectByteBuffer 的总大小，每次申请，都先看看是否超限,堆外内存的限额默认与堆内内存(由 -Xmx 设定)相仿，可用 -XX:MaxDirectMemorySize 从新设定。
若是不指定，该参数的默认值为 Xmx 的值减去1个 Survior 区的值。 如设置启动参数 -Xmx20M -Xmn10M -XX：SurvivorRatio=8,那么申请 20M-1M=19M 的DirectMemory 若是已经超限，会主动执行 Sytem.gc()，期待能主动回收一点堆外内存。System.gc() 会触发一个 full gc，固然前提是你没有显示的设置 -XX:+DisableExplicitGC 来禁用显式GC。而且你须要知道，调用 System.gc() 并不可以保证 full gc 立刻就能被执行。而后休眠一百毫秒，看看 totalCapacity 降下来没有，若是内存仍是不足，就抛出 OOM 异常。若是额度被批准，就调用大名鼎鼎的sun.misc.Unsafe去分配内存,返回内存基地址
在发生这种异常时，通常经过 JMX 的java.nio.BufferPool.direct里面的属性去监控直接内存的变化以及使用（其实就是 BufferPoolMXBean ），来定位问题。
6. OutOfMemoryError: map failed
这个是 File MMAP（文件映射内存）时，若是系统内存不足，就会抛出这个异常，对应的源代码是：
- Windows：FileDispatcherImpl.c
- Linux：FileDispatcherImpl.c
以 Linux 为例：
JNIEXPORT jlong JNICALL
Java_sun_nio_ch_FileChannelImpl_map0(JNIEnv *env, jobject this,
jint prot, jlong off, jlong len)
{
void *mapAddress = 0;
jobject fdo = (*env)->GetObjectField(env, this, chan_fd);
jint fd = fdval(env, fdo);
int protections = 0;
int flags = 0;
if (prot == sun_nio_ch_FileChannelImpl_MAP_RO) {
protections = PROT_READ;
flags = MAP_SHARED;
} else if (prot == sun_nio_ch_FileChannelImpl_MAP_RW) {
protections = PROT_WRITE | PROT_READ;
flags = MAP_SHARED;
} else if (prot == sun_nio_ch_FileChannelImpl_MAP_PV) {
protections = PROT_WRITE | PROT_READ;
flags = MAP_PRIVATE;
}
//调用mmap
mapAddress = mmap64(
0, /* Let OS decide location */
len, /* Number of bytes to map */
protections, /* File permissions */
flags, /* Changes are shared */
fd, /* File descriptor of mapped file */
off); /* Offset into file */
//内存不足时，抛出OutOfMemoryError
if (mapAddress == MAP_FAILED) {
if (errno == ENOMEM) {
JNU_ThrowOutOfMemoryError(env, "Map failed");
return IOS_THROWN;
}
return handle(env, -1, "Map failed");
}
return ((jlong) (unsigned long) mapAddress);
}
这种状况下，考虑：
- 增长系统内存
- 采用文件分块，不要一次 mmap 很大的文件，也就是减小每次 mmap 文件的大小
7. OutOfMemoryError: Requested array size exceeds VM limit
当申请的数组大小超过堆内存限制，就会抛出这个异常。
8. OutOfMemoryError: Metaspace
Metadata 占用空间超限（参考上面简述 Java 内存构成， class 这一块 包含两种，一种是 metadata，一种是 class space），会抛出这个异常，那么如何查看元空间内存呢？
能够经过两个命令，这两个输出是同样的：
- jmap -clstats <PID>
- jcmd <PID> GC.class_stats （这个须要启动参数： -XX:+UnlockDiagnosticVMOptions）
Index Super InstBytes KlassBytes annotations CpAll MethodCount Bytecodes MethodAll ROAll RWAll Total ClassName
1 -1 214348176 504 0 0 0 0 0 24 616 640 [C
2 -1 71683872 504 0 0 0 0 0 24 616 640 [B
3 -1 53085688 504 0 0 0 0 0 24 616 640 [Ljava.lang.Object;
4 -1 28135528 504 0 0 0 0 0 32 616 648 [Ljava.util.HashMap$Node;
5 17478 12582216 1440 0 7008 64 2681 39040 11232 37248 48480 java.util.ArrayList
.........
25255 25 0 528 0 592 3 42 568 448 1448 1896 zipkin2.reporter.metrics.micrometer.MicrometerReporterMetrics$Builder
472572680 16436464 283592 41813040 225990 8361510 75069552 39924272 101013144 140937416 Total
335.3% 11.7% 0.2% 29.7% - 5.9% 53.3% 28.3% 71.7% 100.0%
Index Super InstBytes KlassBytes annotations CpAll MethodCount Bytecodes MethodAll ROAll RWAll Total ClassName
其中，每一个指标的含义以下所示：
- InstBytes：实例占用大小
- KlassBytes：类占用大小
- annotations：注解占用大小
- CpAll：常量池中占用大小
- MethodCount：方法个数
- Bytecodes：字节码大小
- MethodAll：方法占用大小
- ROAll：只读内存中内存占用
- RWAll：读写内存中内存占用
9. OutOfMemoryError: Compressed class space
class space 内存溢出致使的，和上一个异常相似，须要查看类信息统计定位问题。
10. OutOfMemoryError: reason stack_trace_with_native_method
这个发生在 JNI 调用中，内存不足