切中要害。 哈喽大家好啊，今天想跟大伙儿聊聊这个Java虚拟机，也就是咱们常说的JVM。这玩意儿真的挺复杂的，刚接触的时候我头都大了。我也在网上查了很多资料，看了好多视频，感觉还是云里雾里的。但是吧，既然干了这行，不学点这东西以后怎么混啊？所以我就想一下到底怎么才能学会JVM，特别是那个编译器原理，还有怎么生成代码。其实这就像学开车，你得先懂引擎怎么转，油门怎么踩，不然光会踩离合有啥用。

什么是Java虚拟机，它到底是个啥？

就算.... 很多人可能觉得JVM就是一个运行Java程序的软件。其实也不全对，它更像是一个中间人。咱们写的Java代码，是给人看的，是那种高级语言。但是电脑这个大笨蛋，它只认识0和1，就是那种机器码。所以中间得有个东西，把咱们写的那些花里胡哨的Java代码，翻译成机器能懂的语言。这个中间人就是JVM。

JVM这东西，它不仅仅是个翻译器哦。它还管着内存，管着垃圾回收，管着线程。所以说它是个虚拟机，是主要原因是它模拟了一个计算机的硬件环境。在这个环境里咱们写的代码跑得就像真的在硬件上跑一样。只不过这个硬件是假的，是软件模拟出来的。所以要想学好Java，必须得把JVM搞明白。搞不懂它，你的代码写得再漂亮，运行起来慢得像蜗牛，你也找不出原因。我就吃过亏，写了个循环跑了几万次后来啊卡死了找了半天才发现是JVM没调好。

JVM的内部结构，咱们得看看

JVM里面其实有很多东西。有好几块内存区域，比如方法区、堆、栈、程序计数器什么的。这些地方都存着什么数据呢？方法区里存的是类的信息，代码什么的。堆里存的是对象，就是咱们new出来的那些东西。栈里存的是方法调用的过程。这些结构虽然听着枯燥，但是是基础中的基础。如果你连内存怎么分都不知道，去谈什么优化，那简直就是瞎扯淡，一言难尽。。

哭笑不得。 而且JVM还分很多种，有HotSpot，有JRockit，还有OpenJDK。现在咱们用的最多的就是HotSpot了。它里面有两个很厉害的编译器， 一个叫Client Compiler，一个叫Server Compiler。这两个家伙平时都在干嘛呢？它们就是在咱们程序跑的时候，偷偷地把字节码翻译成机器码。这个翻译的过程，就是编译器原理的核心了。

编译器原理，到底是怎么编译的？

纯属忽悠。 说到编译器原理，这可是个大学问。简单编译器就是要把源代码转换成目标代码。在Java里源代码是.java文件，目标代码是.class文件，也就是字节码。这个过程其实分好几步呢。步是语义分析，就是看看这代码逻辑通不通。再说说是中间代码生成和优化，这一步最关键，也是最难懂的。

中间代码生成之后编译器就会开始干活了。它会看看这段代码能不能跑得更快。比如它发现有一个循环跑了好多遍，它就会想，哎，我是不是可以把这个循环展开一下？或者把里面的变量存到寄存器里别老去内存里取了这样会快很多。这就是所谓的优化。不过优化也是有风险的，万一优化错了程序就会崩，所以JVM在优化的时候非常小心。

解释器与编译器，到底谁更厉害？

以前啊，Java是靠解释器来跑的。解释器就像是个翻译官，一行一行地读代码，翻译一句，跑一句。这种方式简单是简单，但是速度慢啊，主要原因是它得来回翻译。后来有了JIT编译器， 说真的... 情况就不一样了。JIT编译器就像是一个学霸， 它看代码看得多了发现这代码经常被调用，它就干脆把它一次性全翻译成机器码，以后再跑就直接用翻译好的了不用再翻译了。

但是JIT也不是万能的。它得等代码跑一会儿，收集一些数据，看看哪些代码是热点代码，然后才去优化。这就有个问题，刚启动的时候，程序得等JIT把代码都优化完了才能跑得快。 是不是？ 这中间的这段时间，程序还是得靠解释器跑，所以启动速度可能没那么快。这就引出了后面要说的AOT技术。

AOT技术，提前编译到底是个啥？

AOT，全称是Ahead-Of-Time，翻译过来就是“提前编译”。听着名字就挺厉害的吧？意思就是在程序还没开始跑的时候， 反正吧… 就把代码给编译好了。这样程序一启动，直接就能用编译好的机器码，不用等JIT去慢慢翻译了。这肯定很快啊，对吧？

像现在很火的GraalVM，它就支持AOT编译。你写好Java代码，编译的时候直接把它变成C++或者机器码。这样程序启动瞬间就完成了占用内存也小。 操作一波... 这对于那些对启动时间要求特别高的程序简直就是救命稻草。比如一些服务器端的程序，或者一些手机上的APP，启动快一点，用户体验就好很多。

JIT和AOT的较量，到底怎么选？

但是呢，AOT也不是完美的。它也有缺点。主要原因是它是在程序还没跑的时候编译的，所以它不知道程序运行起来之后会发生什么。比如你在代码里写了些很随机的逻辑，或者依赖了一些外部环境的数据。 容我插一句... AOT编译的时候这些数据都没有，它就只能做一些很通用的优化。等程序真正跑起来发现情况跟它想的不一样，那刚才做的优化可能就没用了。

而JIT呢，它是在程序跑的过程中编译的，它能看到实时的数据。所以它能做一些更深入的优化，针对具体的运行情况来调整代码。这就好比一个老师， AOT编译器是提前备课，照着教案讲；JIT编译器是边讲边改教案，根据学生的反应随时调整。所以JIT在处理一些峰值性能的时候，往往比AOT要强，往往.….。

所以说这两种技术各有各的好，也各有各的坏。咱们不能说谁比谁强。到底选哪个，得看具体情况。要是你的程序特别看重启动速度， 扯后腿。 那AOT可能更适合你。要是你的程序特别看重运行时的性能，而且启动速度要求没那么高，那JIT可能更好。

综合上述内容可知， JIT和AOT各有千秋，在选择编译方法时需要综合考虑语言特性、 离了大谱。 类型系统等，在一些情况下还可以使用两者的组合。

绝了... 比如有些系统，它一开始用AOT编译，保证启动快，跑起来之后再用JIT慢慢优化。这样既有了启动速度，又有了运行性能。这就是所谓的混合编译模式。这种模式现在在很多高性能的Java应用里都用得挺多的。

代码生成技巧，怎么写出JVM喜欢的代码？

既然知道了JIT和AOT的区别， 那咱们在写代码的时候，怎么才能让JVM编译得更爽，让程序跑得更快呢？这其实就是代码生成技巧的问题了。这东西其实挺玄学的，但是也有一些规律可循，至于吗？。

先说说你得让JVM知道哪些代码是热点。怎么知道呢？你得多跑跑那个代码。如果你写了一段代码，后来啊永远只跑一次那JIT肯定不会去优化它。你得让它在循环里跑个几万次JVM才会觉得“哎，这段代码挺重要的，值得优化”。所以 在设计算法的时候，尽量让热点代码集中在一些地方，不要到处都是热点，那样JVM的优化压力就太大了。

操作一波... 接下来你要注意控制对象的大小。对象太大，JVM在分配内存的时候就会慢，而且在垃圾回收的时候也费劲。JVM最喜欢那种小对象，主要原因是它可以用一些很高效的分配策略。比如TLAB，就是线程本地分配缓冲，专门给小对象用的。所以尽量把大的对象拆分成小的对象，可能会提高性能。

深入理解字节码， 看懂指令集

官宣。 要想掌握编译器原理，光看Java代码是不够的，你得看懂字节码。字节码是JVM能读懂的语言。虽然它不直接是机器码，但是它离机器码很近了。你可以用javap这个工具去反编译.class文件，看看里面的指令都是啥。

反正吧… 字节码指令其实挺少的，大概两百多条。但是组合起来变化无穷。比如iload指令是加载int，astore是存储。这些指令对应着Java代码里的各种操作。如果你能看懂字节码，你就能知道JVM在施行你的代码时到底是怎么操作的。有时候你会发现，JVM生成的字节码跟你写的Java代码不太一样，甚至会做一些优化。比如你写了一个复杂的表达式，JVM可能会把它拆成几步来施行，或者利用一些数学技巧来简化计算。这就是代码生成的艺术啊。

逃逸分析，别让变量乱跑

呃... 逃逸分析是JVM优化里一个很重要的概念。简单就是分析一个对象在方法里创建之后会不会被这个方法之外的代码引用到。如果一个对象在方法里创建了 但是没有逃逸出去，只是在这个方法里用用，那JVM就可以把这个对象直接优化掉，或者把它放在寄存器里。

比如你写了个方法，里面new了个对象，然后转手就用了用完就不管了也没传出去。那JVM就可以认为这个对象根本就不存在或者说它就是一个局部变量，直接用寄存器存就行了。这样既省了内存，又省了垃圾回收的时间。这可是性能提升的一大法宝。所以尽量把变量控制在一个小的作用域里别让它们到处乱跑，这能让JVM更容易做逃逸分析。

内存布局，栈与堆的故事

太硬核了。 代码生成的时候，内存布局也是个大学问。Java里有栈，有堆，还有方法区。栈是存方法调用过程的，是线程私有的。堆是存对象的，是线程共享的。方法区是存类信息的，也是共享的。

在生成代码的时候，JIT需要决定把变量放在栈上还是堆上。栈上的访问速度非常快，主要原因是它是寄存器级别的。但是栈空间很小，而且生命周期短。堆上的访问速度慢一点，主要原因是得先找到对象在堆里的地址，然后再去取数据，但是堆空间大，能存很多对象。

所以JIT在优化的时候，会尽量把局部变量放在栈上。如果变量很大，或者生命周期很长，那就只能放在堆上了。这就是为什么咱们写代码的时候， 尽量把局部变量写清楚，别声明成全局的，这样JVM才能更好地优化内存布局。

内联，把大函数变小函数

掉链子。 内联是编译器优化里最常用也最有效的方法之一。它的意思就是把一个函数调用，直接替换成函数体里的代码。比如你调用了A函数， A函数里只有两行代码，那编译器就直接把这两行代码复制到调用的地方，不用再去跳来跳去调A函数了。

这样做的好处是减少了函数调用的开销，比如保存现场、恢复现场、跳转什么的。而且编译器还能对内联后的代码做更多的优化，比如常量传播、死代码消除等等。不过内联也不是随便就能干的。如果函数太大了内联之后会导致代码膨胀，反而影响性能。所以JIT会根据一些启发式算法，决定哪些函数适合内联，哪些不适合，出岔子。。

垃圾回收， 编译器也得配合

虽然垃圾回收主要是GC的工作，但是编译器在生成代码的时候，也得考虑GC的因素。比如如果你老是创建大量的小对象，那GC的压力就大，程序就会停顿。编译器可以通过一些技巧来减少GC的压力，你猜怎么着？。

比如复用对象。如果你创建了一个对象，用完之后不用马上回收，而是把它设为null，下次再用的时候直接重用。这样就不需要再分配新的内存了也就减少了GC的工作量。虽然这个技巧在现代JVM里可能效果没那么明显了 主要原因是JVM已经很聪明了但是了解这个原理还是很有用的。

分支预测，怎么让CPU不傻等？

CPU在施行代码的时候，有时候会遇到分支，比如if-else，或者for循环。CPU不知道分支会走向哪边，所以它只能老老实实地一条一条往下施行。如果预测错了就得回退，这很浪费时间，地道。。

编译器在生成代码的时候，会尽量帮助CPU做分支预测。比如把最可能施行的分支放在前面或者使用一些特殊的指令来提示CPU。JIT在分析代码的时候，也会发现一些分支模式，然后生成一些能优化分支预测的代码。这涉及到计算机体系结构的知识，挺深奥的，但是懂一点对提高性能很有帮助，改进一下。。

一下 虽然很乱但很有道理

说了这么多，其实也就是想告诉大家，Java虚拟机里的编译器原理和代码生成技巧，真的挺复杂的。它不是简单的翻译，而是一门艺术。它要在性能、内存、启动速度之间找到一个平衡点。

咱们写代码的时候， 虽然不用太刻意去迎合JVM的优化策略，但是了解一些基本原理，比如逃逸分析、内联、栈堆分配等等，能帮助我们写出更高效、更稳定的代码。遇到性能问题的时候，也能更好地去排查原因，物超所值。。

实锤。 AOT又叫静态编译， 是指在运行前编译源代码，无须运行时开销，一边可以应用很多重量级的耗时优化，使编译后的机器代码能够快速启动，占用内存较小。但是AOT缺少程序运行时的信息，对某些程序的峰值性能优化有限。

我倾向于... 所以啊，学习JVM这条路还很长。我也还在学习的过程中，希望今天说的这些大白话能帮到大家。大家有问题的话，可以在下面留言，咱们一起讨论。毕竟技术这东西，越学越觉得自己不懂。不过只要肯学，总会有进步的。希望以后大家都能写出那种跑得飞快、内存占用又低的Java程序。加油吧，打工人！

---