21 | 方法内联（下）

IR 图分析看了这三篇，好几次，现在还是不甚明白，

是每个对象有type profile的限制么？

我也不清楚，什么时候可以有完整的profile，什么时候是不完整的

老师，想请教一下，“类型Profile”完整还是不完整，是如何判断的？

感觉跟不上了，先过吧！ 已经拉下两节了，日后回头再看看。 现在仅明白，方法内联-是编译器的一种代码优化手段，会根据不同代码调用方式有不同的优化方式，目的都是为了提高JVM的效率，根本方式，我认为就是采用取巧的方式，提前判断出来可以少做一些事情，然后先提前做一些准备，整体的时间和空间成本会降下来。 另外，提供小建议，雨迪能否对于这种比较比较抽象的知识，来点生动形象的比喻以便帮助消化，之前在知乎看到一篇关于锁的文章，全篇通过生动形象的比喻讲解锁的本质、分类、各种锁的特点，读起来一下子就明白了。

漫漫长路，这JAVA一门语言就要如此深究，真特么知无涯

方法内联就是将调用的目标方法，内联到调用者方法里面，以避免目标方法的重复调用带来的开销，但是在内联时，如果目标方法，完全确定，也就是说，目标方法的调用是唯一的，那么直接内联就可， 但是由于Java的多态特性，基于接口而非实现编程等，导致目标方法的调用的需要在运行时确定，也就是虚方法的调用在即时编译阶段无法确定唯一调用的目标方法版本，而内联是在即时编译阶段。 一部分方法的符号引用在编译阶段就可以确定唯一的调用版本，但是一部分必须在运行时才能将符号引用替换为直接引用，这就导致，在即时编译器进行内联时，这部分方法没法确定唯一的调用版本，于是就有去虚化手段，把虚方法调用通过一定的去虚化手段，直接替换为直接调用，保证内联后的方法在实际运行时不会出错。 去虚化的手段，只能尽量保证虚方法的调用能直接替换为直接调用，只有准确的替换，才能体现出内联的优势，如果实在确定不了虚方法调用的准确版本，那么就去优化，也就是不内联了。 基于类型的去虚化：通过对象的静态类型，实际类型，一些重载，重写方法的调用，其实编译器能通过具体的数据类型，进行识别。可以说一旦识别，就准确无误。 基于层次的去虚化：完全依赖于jvm类的加载，基于只加载一个类的假设。适用场景很受限。 基于条件的去虚化：依赖于分层编译时收集的数据。 总的来说，内联带来的程序运行的性能提升要远远大于内联的成本。方法内联，为的就是把即时编译的性能发挥到极致。都是为性能考虑的。

为什么后面留言的人越来越少了，我觉得后面这些也很关键很有趣呀。对思想的提升很有帮助的。

免费的才是最贵的，享受便利的同时，想搞明白确实不容易，我只有个大的概念。感觉这可以类比CPU里面的冒险与预测来理解，都是基于某种方式来优化，让程序跑的更快些。

基于类型推导的完全去虚化 基于类层次分析的完全去虚化 条件虚拟化 目录挺清楚的，极客时间的文章出个标题侧栏就更好了。