1. 先搞清楚逃逸分析到底在解决什么问题如果你在面试中被问到JVM调优或者在生产环境排查内存问题时听到“逃逸分析”这个词第一反应是不是觉得它很深奥离日常开发很远其实恰恰相反它解决的是一个非常实际且高频的问题如何让Java程序在堆上少创建一些对象从而降低GC压力提升运行效率。简单来说逃逸分析是JVM在即时编译阶段JIT做的一种高级优化。它的核心任务就是分析一个在方法内部创建的对象其生命周期和引用范围是否“逃逸”出了这个方法。如果分析发现这个对象没有逃逸JVM就可以进行一系列“胆大”的优化比如栈上分配、标量替换、锁消除。这些优化的最终目的就是避免在堆上分配这个对象或者简化它的结构。为什么这个很重要因为堆是GC的主战场。每一次Young GC都在清理堆里短暂存活的对象。如果一个对象只在方法内部使用方法结束它就“死”了那把它放在堆里就是给GC系统增加无谓的负担。逃逸分析就是JVM的“智能管家”试图识别出这些“短命”对象并想办法让它们别去堆里凑热闹。所以这篇文章不是给你罗列教科书定义。我会带你从现象、原理、验证、到生产环境的意义走一遍。你会明白为什么有些代码微小的改动就能带来性能提升以及面试官问你“逃逸分析”时他真正想听到的是什么。2. 对象的一生逃逸与不逃逸的差别要理解优化先得理解什么是“逃逸”。我们可以把对象想象成一个在方法里出生的“孩子”。2.1 什么是“逃逸”当一个对象在方法内部被创建后如果它的引用被传递到了方法外部被其他方法或线程所引用以至于在方法结束后这个对象可能还被使用我们就说这个对象“逃逸”了。逃逸的典型场景方法返回值这是最常见的逃逸。public User createUser() { User user new User(); // 对象被创建 user.setName(超天酱); return user; // 引用被返回对象逃逸了 }赋值给类成员变量或静态变量对象被“挂”在了类的全局状态上。public class Holder { private static Object staticObj; private Object instanceObj; public void escapeToStatic() { staticObj new Object(); // 逃逸到静态域 } public void escapeToInstance() { this.instanceObj new Object(); // 逃逸到实例域 } }作为参数传递给其他“未知”方法如果传入的方法可能将引用保存起来也算逃逸。public void registerCallback(Callback cb) { this.callbackList.add(cb); // 如果add方法保存了cb则cb逃逸了 } public void test() { Callback myCb new Callback(); // 可能逃逸 registerCallback(myCb); }被线程引用对象被另一个线程访问肯定逃逸因为生命周期超越了当前方法栈。2.2 什么是“未逃逸”如果一个对象在方法内部创建并且其引用完全局限在方法体内随着方法调用的结束这个对象就变得不可达可以被销毁。这就是“未逃逸”或“非逃逸”对象。未逃逸的典型场景public int calculateSum(int a, int b) { // 这个Calculator对象只在calculateSum方法内使用 Calculator calc new Calculator(); // 未逃逸对象 int result calc.add(a, b); // 方法结束calc引用消失对象再无引用可被回收 return result; }在这个例子里Calculator对象没有作为返回值没有赋值给外部变量没有传给可能存下它的外部方法。它的一生都局限在calculateSum这个方法的栈帧里。关键判断逃逸分析发生在JIT编译时JVM会进行复杂的数据流分析来判断对象的逃逸状态。它不是百分百准确的属于一种“乐观优化”。3. JVM的“三板斧”基于逃逸分析的优化手段识别出未逃逸对象后JVM就可以施展它的优化魔法了。主要有三种这也是面试常考点。3.1 栈上分配是什么如果确定一个对象不会逃逸出方法那么JVM可以选择不在堆上分配内存而是直接在当前线程的Java虚拟机栈上分配内存。这听起来有点反常识因为《Java虚拟机规范》说所有对象实例都在堆上分配。但请注意规范是“Java虚拟机”的规范而“栈上分配”是具体JVM实现如HotSpot的一种优化手段它并没有违反对象可被GC回收的语义。为什么有效栈上分配的对象其内存空间位于栈帧中。当方法调用结束时栈帧弹出这块内存就直接被释放了完全不需要垃圾回收器介入。这极大地降低了堆的压力和GC的频率。限制栈空间通常比堆小得多所以只有小对象且生命周期极短的未逃逸对象才适合栈上分配。大对象强行栈上分配可能导致栈溢出。3.2 标量替换是什么“标量”是指一个无法再分解的数据如基本数据类型int, long等和对象引用。“聚合量”就是对象它可以被分解成多个标量。 如果逃逸分析证明一个对象不会被外部访问并且这个对象可以被拆散那么程序执行时可能根本不创建这个对象而是直接创建它的成员变量标量在栈上或寄存器中分配。例子最直观public class Point { private int x; private int y; // getter/setter... } public void foo() { Point p new Point(); // 未逃逸对象 p.setX(1); p.setY(2); int distance p.getX() p.getY(); // ... 仅使用p的x和y }经过逃逸分析和标量替换优化后JIT编译器可能会把代码“重写”成这样public void foo() { // 没有Point对象被创建 int x 1; // Point的x成员被替换为局部变量 int y 2; // Point的y成员被替换为局部变量 int distance x y; }你看整个Point对象消失了变成了栈上的两个局部变量x和y。这比分配一个对象高效得多。这是最彻底的优化连对象头存储哈希码、GC年龄、锁状态等信息的内存开销都省了。3.3 锁消除是什么synchronized锁是Java中一个重量级的操作。但如果逃逸分析能证明一个被synchronized修饰的对象绝对不会被其他线程访问即不仅未逃逸出方法甚至未逃逸出当前线程那么对这个对象加的锁就是毫无意义的。JIT编译器会直接移除这些同步操作。典型场景在方法内部使用线程安全的集合类如StringBuffer。public String concatString(String s1, String s2, String s3) { StringBuffer sb new StringBuffer(); // sb对象未逃逸出此方法 sb.append(s1); sb.append(s2); sb.append(s3); return sb.toString(); }StringBuffer的append方法是synchronized的。但在这个例子中sb对象是方法内局部变量不会被其他线程共享。因此逃逸分析可以判定这里的锁是多余的JIT编译时会消除这些锁操作使其性能与StringBuilder无异。注意锁消除是建立在“确定无并发访问”的基础上。如果对象可能逃逸比如被传入一个可能被多线程调用的方法锁就不能被消除。4. 如何验证和观察逃逸分析的效果光说原理不够我们得能验证。但逃逸分析是JIT编译器的内部优化默认开启我们无法直接“看到”栈上分配或标量替换的发生。不过可以通过一些间接手段来观察其影响。4.1 通过GC日志对比这是最有力的证据。我们可以写两段逻辑相似的代码一段创建逃逸对象一段创建未逃逸对象然后对比它们的GC行为。测试思路编写一个循环创建大量临时对象。一组测试中让对象逃逸如存入集合。另一组测试中确保对象未逃逸仅在循环内使用。使用JVM参数-XX:PrintGC或更详细的-XX:PrintGCDetails来打印GC日志。观察两组测试的GC次数和暂停时间。示例代码框架public class EscapeAnalysisTest { private static ListObject list new ArrayList(); // 用于“捕获”逃逸对象 // 测试逃逸场景对象被加入全局列表 public static void testWithEscape() { for (int i 0; i 1000000; i) { Object obj new Object(); // 这个对象逃逸了 list.add(obj); // 逃逸发生在这里 } list.clear(); // 测试后清空避免影响下次测试 } // 测试未逃逸场景对象仅在循环内使用 public static void testWithoutEscape() { long sum 0; for (int i 0; i 1000000; i) { Object obj new Object(); // 这个对象未逃逸 sum obj.hashCode(); // 仅内部使用方法结束即消亡 } System.out.println(sum); // 防止循环被优化掉 } public static void main(String[] args) throws InterruptedException { // 先预热让JIT编译发生 for (int i 0; i 10000; i) { testWithoutEscape(); } Thread.sleep(1000); // 等待编译完成 System.out.println(开始测试逃逸场景...); long start System.currentTimeMillis(); testWithEscape(); System.out.println(逃逸场景耗时: (System.currentTimeMillis() - start)); System.gc(); // 手动触发一次Full GC清理堆 Thread.sleep(1000); System.out.println(开始测试未逃逸场景...); start System.currentTimeMillis(); testWithoutEscape(); System.out.println(未逃逸场景耗时: (System.currentTimeMillis() - start)); } }运行参数-XX:PrintGC -Xmx100m -Xms100m把堆设小更容易触发GC预期观察结果testWithEscape方法很可能会触发多次Minor GC而testWithoutEscape方法可能一次GC都没有或者次数极少。耗时上未逃逸版本也应该显著更优。这间接证明了逃逸分析带来的优化栈上分配/标量替换减少了堆内存分配和GC压力。4.2 通过JVM参数控制逃逸分析是默认开启的优化。我们可以通过JVM参数关闭它来对比性能。-XX:DoEscapeAnalysis开启逃逸分析默认-XX:-DoEscapeAnalysis关闭逃逸分析-XX:EliminateAllocations开启标量替换依赖逃逸分析默认开-XX:-EliminateAllocations关闭标量替换-XX:EliminateLocks开启锁消除依赖逃逸分析默认开-XX:-EliminateLocks关闭锁消除测试方法用上面的测试代码分别用默认参数和-XX:-DoEscapeAnalysis参数运行对比耗时和GC日志。关闭优化后性能下降和GC增多会非常明显。4.3 使用JMH进行微基准测试对于性能对比推荐使用Java Microbenchmark Harness (JMH)它能避免很多手工测试的陷阱如JIT预热、编译器优化等。 你可以编写两个JMH Benchmark方法一个用逃逸写法一个用非逃逸写法来科学地测量其吞吐量差异。5. 生产环境与面试逃逸分析的实战意义理解了原理和验证方法我们最后落到实战和面试上。5.1 对日常编码的指导逃逸分析是JVM的自动化优化我们不需要、也不应该为了迎合它去刻意扭曲代码结构。但是了解它有助于我们写出更“优化友好”的代码尽量缩小对象的作用域这是一个普适的好习惯。如果一个对象只在方法内或循环内使用就不要把它定义为成员变量或传递到可能保存其引用的外部方法中。这给了JVM最大的优化空间。理解“无意义的同步”对于像上面StringBuffer的例子如果你能确定上下文是线程安全的直接使用StringBuilder是更清晰的选择。不要依赖JVM的锁消除因为它的判断条件很严格。不要过度优化逃逸分析是JIT编译器在运行时的优化。在代码可读性和微小的性能潜在收益之间永远优先选择可读性和正确性。不要为了“帮助”逃逸分析而把代码写得晦涩难懂。5.2 在JVM调优和问题排查中的位置当你在处理“离线排查JVM内存飙升问题”时逃逸分析不是你的第一线工具。内存飙升通常要优先排查内存泄漏如静态集合持续增长。不合理的缓存策略。过大的对象如大数组、大字符串。不合理的JVM参数如堆大小设置不当。但是在性能调优的深水区当你通过Profiler如Async Profiler, JProfiler发现大量短生命周期小对象在频繁分配和回收导致GC压力很大时你可以回过头来审视代码结构。看看这些对象是否有逃逸的必要能否通过重构缩小其作用域从而“暗示”JVM进行更激进的优化。这属于一种更高级的、代码层面的调优手段。5.3 面试中如何回答“逃逸分析”面试官问这个问题通常想考察你对JVM底层优化的了解深度不止于GC。你能否将原理、优化、实践串联起来。 一个结构化的回答可以这样组织“逃逸分析是JVM在JIT编译期做的一种分析目的是判断一个在方法内创建的对象其引用是否会逃逸到方法外部或线程外部。如果分析证明对象不会逃逸JVM就可以进行三种关键优化 第一是栈上分配直接在栈帧上分配对象方法结束自动销毁减轻GC负担。 第二是标量替换这是更彻底的优化直接把对象拆成它的成员变量标量来使用根本不在堆上创建这个对象。 第三是锁消除如果锁住的对象被证明是线程私有的就会消除这个无意义的同步操作。 这些优化都是为了减少堆内存分配、降低GC频率、提升程序性能。在实际开发中我们虽然不直接控制它但遵循‘尽量缩小局部变量作用域’的好习惯能为JVM的逃逸分析创造更好的优化条件。在排查极端性能问题时如果发现大量短命小对象导致GC频繁可以结合Profiler工具从逃逸分析的角度审视代码结构是否合理。”这样回答既体现了原理理解又关联了实践和调优比单纯背定义要强得多。6. 边界与误区逃逸分析不是万能的最后必须划清边界避免产生误解。它是一项编译期优化有开销逃逸分析本身需要消耗CPU时间进行复杂的静态分析。对于执行次数很少的“冷”方法JVM可能不会对其进行JIT编译自然也就没有逃逸分析。只有那些被频繁执行的“热点”代码才会触发。分析结果不是百分百准确逃逸分析基于静态分析对于通过复杂反射、动态代理或Native方法传递引用的场景分析可能保守地认为对象逃逸了从而放弃优化。它不改变语言语义无论是否优化程序的运行结果必须是一致的。优化是透明的。不能替代良好的设计不要指望逃逸分析来拯救糟糕的架构。一个在方法间传来传去的大对象即使逃逸分析判定它“逃逸”了而无法优化这本身也说明你的设计可能有问题。优化应该是锦上添花而不是雪中送炭。与JVM内存模型JMM的关系逃逸分析和Java内存模型关注的是不同层面。JMM定义的是多线程环境下变量的可见性、有序性规则如happens-before。而逃逸分析中的“线程逃逸”是判断对象是否可能被多线程访问这是进行锁消除的前提但两者概念不同。总结一下逃逸分析是JVM为了提升性能在后台默默进行的“精打细算”。作为开发者我们最好的策略是写出作用清晰、结构良好的代码为JVM的优化器铺平道路而不是去猜测和迎合其具体的优化规则。当遇到性能瓶颈时知道有这么一个工具在起作用能帮助你在更深的层次思考问题所在。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
