反射调用使逃逸分析直接放弃，因其动态性破坏静态引用图构建；jvm保守标记对象为globalescape，强制堆分配以确保内存安全。
反射调用会让逃逸分析“直接放弃”，不是因为分析能力弱，而是它根本无法建模运行时才确定的行为。逃逸分析是静态的，而反射是动态的——两者在设计层面就对立。
反射切断引用链的静态可推导性
逃逸分析依赖构建变量间的确定引用图：比如 p = new Point() → field.x = p → 若 field 是静态字段或被传入未知方法，就标记为 GlobalEscape。但反射操作（如 Field.set(obj, value) 或 Method.invoke(target, args)）在源码里只体现为几个字符串参数和通用类型，编译器看不到实际赋值目标是谁、是否写入静态容器、是否跨线程暴露。
例如：
- Field.set(o, p) 中，o 和 p 的具体类型、o 是否是单例对象、该 Field 是否属于某个被多线程共享的类——全靠运行时决定
- Method.invoke(x, y) 可能内部把 y 加进全局缓存，也可能只是本地计算，编译器无从知晓
- 甚至 reflect.Value.Addr() 这类操作，在 Go 中类似逻辑也会让逃逸分析退避，Java 同理：地址取出来之后怎么用？谁持有？静态阶段无法表达
类型擦除与反射入口不可追踪
Java 的泛型和反射共同导致引用路径断裂。比如：
- 一个 List> 通过反射 add 了一个局部对象，编译器不知道这个 list 实际指向的是 static List 还是某个栈上临时 list
- Class.forName("xxx").getDeclaredConstructor().newInstance() 创建的对象，其后续是否被赋给静态变量？是否被返回？没有字节码层面的显式赋值语句，逃逸分析图中就没有对应边
- 反射调用常伴随 setAccessible(true)，这本身已是 JVM 对封装模型的绕过，也意味着编译器不能再依赖访问修饰符做保守假设
JVM 的保守策略：宁堆勿栈
一旦检测到任意一处反射调用，JVM 并不会尝试“部分分析”剩余代码，而是直接将涉及对象标记为 GlobalEscape。这不是懒，而是安全必须：
- 栈上分配要求对象生命周期严格绑定于当前栈帧；若反射意外将其地址泄露给堆中长期存活结构，方法返回后栈帧销毁，就会产生悬垂指针
- 即便反射调用看似“没逃逸”（比如只读取字段），JVM 也无法证明它未来不会被其他反射路径修改或传播——静态分析不能依赖“这次没做”来推断“永远不做”
- HotSpot 中，只要方法体包含 invokevirtual java/lang/reflect/Method.invoke 或类似反射字节码，C2 编译器就会跳过对该方法内所有新对象的逃逸优化
和 JNI、Unsafe 的本质一致
反射、JNI、Unsafe 都属于 JVM 的“信任边界出口”。它们让代码脱离 Java 类型系统和内存模型约束，进入运行时不可控区域。逃逸分析不处理这类调用，并非缺陷，而是明确的设计取舍：对不可静态验证的行为，统一按最坏情况处理——对象必须堆分配，确保 GC 能管理其生命周期，杜绝内存错误。
