JIT会翻车。真的会。那天线上一个关键服务突然超时，连带着整个调用链雪崩，最后定位到——JIT编译线程把CPU吃满了。你盯着监控曲线，那种锯齿状的尖刺，像不像心电图骤停前的波形？
说实话，JIT（Just-In-Time）这词儿有点被神话了。一提到它，仿佛就是性能救世主。不过话说回来，它确实是个精巧的设计——但精巧往往意味着脆弱。我今天不聊教科书上的字节码转机器码，我想扒开那些让你半夜惊醒的细节。
热点探测：你以为的聪明，其实是赌徒心态
JIT的核心是热点探测（Hot Spot Detection）。JVM的HotSpot、V8的TurboFan，搞法大同小异：代码先跑在解释器里，统计方法调用次数、循环回边次数，超过阈值——比如HotSpot默认是10000次——就丢给编译线程。这思路粗暴吗？粗暴。但工程上这叫经验阈值，就跟打牌一样，你总觉得下一把能赢。问题是阈值选得不好，性能直接裂开。
我见过一个案例：某个业务逻辑里藏着个低频但极度耗时的正则匹配。调用次数永远差那么几次够不到10k，解释执行慢得像蜗牛。而旁边一个高频的getter方法，因为天天被调，全身编译优化，最后被内联得渣都不剩。JIT的“聪明”全靠统计，统计是后验的——别忘了这一点。
编译线程会做很多激进优化：内联、逃逸分析、锁消除、虚方法去虚拟化……每个都是双刃剑。内联掉小方法可以消除调用开销，但内联太多，代码体积爆炸，ICache miss飙升，性能反而掉坑里。逃逸分析把堆分配优化成栈分配，但假设某天突然多线程引用了，就得去优化（Deoptimization）——把编译好的机器码丢弃，回退到解释执行，然后再重新编译。这个“突然”，嗯，线上P99延迟就这样飙上去了。
去优化是JIT最让人头疼的机制之一，没有之一。你兴高采烈上了线，凌晨两点被叫醒，就因为一个陷阱（1）：预热期性能大跳水。压测数据漂漂亮亮，一上线原形毕露。为啥？压测是稳态流量，热点早就编好了。线上呢？冷启动，前半分钟还在解释执行，后面编译线程疯狂工作，CPU、内存双双飙高，用户看着转圈圈骂娘。我见过一个支付服务，上线头几分钟成功率骤降8%，就因为JIT预热。
解决方案？提前预热（Warm-up）。别信什么“JIT自动搞定”的鬼话。你得在发布时用流量回放或脚本跑一遍核心链路，触发关键路径的编译。或者用GraalVM的AOT模式先把高频代码编译成本地镜像，彻底避开JIT。代价是牺牲了一些动态优化潜力，但换来的是可预测的延迟——工程上，可预测比峰值性能重要十倍。
性能数据：别只看峰值，看长尾
很多benchmark只提JIT可达C++ 95%的性能——这话没错，但漏了关键前提：稳态、单次调用。真实系统是持续运行的，有GC、有编译、有去优化。我亲手做过一次对照：一个股票交易网关，用C2编译且无去优化的版本，长尾延迟P99.9是12ms；一旦触发去优化，P99.9飙到350ms，吞吐量跌了40%。这就是陷阱（2）：性能震荡。
震荡的根因除了去优化，还有编译抖动（Compilation Thrashing）。假设你代码里有一个多态调用，JIT看到某个子类占了95%，愉悦地做了内联缓存，结果突然冒出一个新子类，缓存失效，重新编译。反复搞几次，CPU全耗在编译上。这种抖动在微服务架构里尤其致命，因为下游依赖一变动，流量特征瞬变。
怎么破？分层编译别瞎关——HotSpot从JDK8开始有C1、C2两层，C1编译快优化少，C2编译慢优化狠。默认下，热点会从C1升C2，但升的过程就是震荡源。对于要求极致稳定的场景，可以固定用C1，牺牲峰值吞吐，换来平滑。还有个狠招：禁用特定方法的编译，加上-XX:CompileCommand=exclude,com/your/Class,method，让它老老实实解释执行。丑，但有用。
调试地狱：当堆栈变得不可信
JIT最反人类的地方——运行时生成的代码没源码对应。你抛了个异常，堆栈里方法名还在，行号却对不上，就是陷阱（3）：调试信息失真。因为内联优化，整个调用链被压扁了，真正的现场在几层机器指令之下。你加个打印日志，位置一调整，编译结果变了，bug神奇消失……那感觉，像在追幽灵。
千万别在生产环境依赖普通调试工具。我强烈推荐：打开-XX:+PrintCompilation和-XX:+LogCompilation，把编译日志扔出来。再配合JITWatch这类可视化工具，看哪些方法被内联、哪些被去优化了。有一回，我们靠着分析日志发现某个lambda表达式被反复编译又丢弃，根源是依赖了一个外部库反射调用的类。这种问题静态分析永远找不到。
还有一个经验：预留逃逸分析的退路。如果你的代码对锁敏感，可以显式用synchronized然后指望JIT消除，但更好的方式是直接用无锁设计。因为JIT的优化承诺不是合同，它可能随时变卦。写一次测试，JIT给了你优化，换个JDK小版本，优化没了，你找谁哭去？
JIT的工程美学是什么？是动态不确定性中寻求局部最优。它像极了金融里的高频交易算法——基于历史预测未来，但永远面临模型失效。理解其机制并不难，难得是接受它的不可控，并为此设计容错。如果有人告诉你他能完全掌控JIT——要么他是超级天才，要么他在吹牛。
最后记住一点：别在生产环境首次暴露JIT。预热、预热、还是预热。那是无数架构师半夜惊醒总结出的血泪定律。对了，下次压测别只盯QPS，看看P99.9和CPU稳态吧，那才是JIT留下的暗门。
