1.JVM详解之:HotSpot VM中的Intrinsic methods
2.JVM之创建对象源码分析
3.hotspotjvm的启动过程做了什么?
4.Java性能优化系列之-JIT即时编译器与Java内存管理机制
5.从HotSpot源码，深度解读 park 和 unpark
JVM详解之:HotSpot VM中的Intrinsic methods
内置方法是编译器内置的方法实现，它们在给定编程语言中使用，由编译器专门处理。内置方法通常在程序请求优化时才启用，以提高效率。桌面分类 源码因为内置方法是在编译器内部实现的，所以不同的虚拟机，其内置方法是不一样的。内置方法可以在Java源代码级别看起来与非内置方法一样，但它们的区别在于JVM的实现。有些方法在普通Java代码中无法实现，如sun.misc.Unsafe.compareAndSwapInt()，只能通过JNI或内置方法来实现，实现对Java语义的扩展。在Hotspot VM中，内置方法通常在src/share/vm/classfile/vmSymbols.hpp类中。通过参数查看代码中调用的方法是否为内置方法，或者通过底层汇编语言查看。内置方法大部分都是内联方法，通过减少函数调用开销的技术实现。内置方法的实现由三种编译器完成：javac将Java源代码编译成为字节码，在这一层只有数学方法和bootstrapping的MethodHandle实现；JIT的Client Compiler (C1)；JIT的Server Compiler (C2)。例如，java.lang.System.currentTimeMillis()方法在Interpreter级别没有intrinsified，因为它是一个native方法，通过JNI调用底层的C++实现。而在C1和C2级别使用intrinsified，直接调用os::javaTimeMillis()，减少JNI的使用，提升效率。内置方法的ospf源码解读实现可以通过修改底层的JVM实现完成。Graal是一个用Java编写的JIT编译器，可以使用Java来实现Intrinsic方法，对于不熟悉C++的开发者来说非常友好。通过Graal，内置方法的实现变得简单且容易操作。内置方法是JVM中非常有用的特性，能够显著提高程序效率，是编程时值得考虑的技术之一。
JVM之创建对象源码分析
欢迎探索我的技术分享：《半栈工程师》 对于Java对象的创建，我过去只是停留在理论层面，但最近研究HotSpot虚拟机时，我深入剖析了JVM创建Java对象的底层机制。Java对象创建流程详解
首先，我们从一个简单的实例开始，看看如何通过代码创建一个Dog对象： 代码中new Dog()在编译成字节码后，会变成new #2，这里的new是实例化对象的关键字，#2则指向常量池中的Dog类索引。常量池是类编译后的存储区域，包含了各种符号引用和常量。new指令源码剖析
接下来，我们将深入new指令的源码。虽然涉及汇编代码，但无需立即深入，先了解一下《JVM之模板解释器》会有所帮助。新指令的运行过程如下：从指令中获取类在常量池的索引，存入rdx寄存器，并记录当前指令地址。
获取常量池地址和元素类型数组_tags，用于后续类型检查。
检查元素类型是freecad源码python否为JVM_CONSTANT_Class，如果不是，进入慢速分配。
获取并入栈类的运行时数据结构InstanceKlass，即类的内存地址。
判断类是否已解析，未解析则执行慢速分配，解析过的进入快速分配。
计算类实例大小并分配内存，首先尝试TLAB区，失败则在Eden区分配。
初始化对象实例数据和对象头。
如果类未解析，执行慢速分配过程。
总结
至此，我们了解了Java对象从创建到初始化的全过程。虽然使用了模板解释器，但理解字节码解释器中的相关方法也是个不错的选择。如果你对HotSpot源码感兴趣，欢迎加入讨论，我的****是wechat：wang_atbeijing。hotspotjvm的启动过程做了什么?
HotSpot JVM启动过程涉及启动器和自身两大部分。
启动器主要负责加载Java类文件，将类文件转换为本地可执行代码，并初始化环境变量和设置。
HotSpot JVM的初始化过程则包括内存分配、类加载、方法区初始化、线程创建等步骤。
启动器通过执行Java解释器或Java虚拟机启动命令来启动HotSpot JVM，典型的启动器包括JRE/JDK自带的java[.exe]和javaw.exe。
Native应用程序也可自定义启动器实现Java启动。波段帝王源码
《Java Performance》一书提供了高阶描述，适合深入理解HotSpot JVM启动机制。
《Java Performance》笔记第页可作为参考。
HotSpot JVM初始化大入口为Threads::create_vm函数，该函数接收JavaVMInitArgs参数，并进行VM初始化。
为了详细了解HotSpot JVM启动过程，建议阅读官方文档和相关书籍，同时也可参考JDK自带的Java launcher源代码。
Java性能优化系列之-JIT即时编译器与Java内存管理机制
JIT（即时编译器）的目的在于提高热点代码的执行效率。在运行时，虚拟机会将这些代码编译成与本地平台相关的机器码，并进行各种层次的优化。完成这一任务的编译器被称为即时编译器（Just In Time Compiler），简称 JIT 编译器。
即时编译器不是虚拟机必需的部分，Java 虚拟机规范并没有规定 Java 虚拟机内必须要有即时编译器的存在，更没有限定或指导即时编译器应该如何去实现。但是，即时编译器编译性能的好坏、代码优化程度的高低却是衡量一款商用虚拟机优秀与否的最关键的指标之一。它也是虚拟机中最核心且最能体现虚拟机技术水平的部分。
目前主流的 HotSpot 虚拟机默认采用一个解释器和其中一个编译器直接配合的方式工作，程序使用哪个编译器，取决于虚拟机运行的模式。在 HotSpot 中，解释器和 JIT 即时编译器是同时存在的，他们是 JVM 的两个组件。对于不同类型的应用程序，用户可以根据自身的特点和需求，灵活选择是wav源码输出基于解释器运行还是基于 JIT 编译器运行。HotSpot 为用户提供了几种运行模式供选择，可通过参数设定，分别为：解释模式、编译模式、混合模式，HotSpot 默认是混合模式，需要注意的是编译模式并不是完全通过 JIT 进行编译，只是优先采用编译方式执行程序，但是解释器仍然要在编译无法进行的情况下介入执行过程。
字节码是指平常所了解的 .class 文件，Java 代码通过 javac 命令编译成字节码。机器码和本地代码都是指机器可以直接识别运行的代码，也就是机器指令。字节码是不能直接运行的，需要经过 JVM 解释或编译成机器码才能运行。Java 源码转换成字节码的过程是由 JVM 执行引擎来完成的。
JVM 的类加载是通过 ClassLoader 及其子类来完成的，类的层次关系和加载顺序可以由下图来描述。Bootstrap ClassLoader 负责加载 $JAVA_HOME 中 jre/lib/rt.jar 里所有的 class，由 C++ 实现，不是 ClassLoader 子类。Extension ClassLoader 负责加载 Java 平台中扩展功能的一些 jar 包，包括 $JAVA_HOME 中 jre/lib/*.jar 或 -Djava.ext.dirs 指定目录下的 jar 包。App ClassLoader 负责记载 classpath 中指定的 jar 包及目录中 class。Custom ClassLoader 属于应用程序根据自身需要自定义的 ClassLoader，如 Tomcat、jboss 都会根据 J2EE 规范自行实现 ClassLoader。
JVM 是基于栈的体系结构来执行 class 字节码的。线程创建后，都会产生程序计数器（PC）和栈（Stack），程序计数器存放下一条要执行的指令在方法内的偏移量，栈中存放一个个栈帧，每个栈帧对应着每个方法的每次调用，而栈帧又是有局部变量区和操作数栈两部分组成，局部变量区用于存放方法中的局部变量和参数，操作数栈中用于存放方法执行过程中产生的中间结果。
编译器：把源程序的每一条语句都编译成机器语言，并保存成二进制文件，这样运行时计算机可以直接以机器语言来运行此程序，速度很快。解释器：只在执行程序时，才一条一条的解释成机器语言给计算机来执行，所以运行速度是不如编译后的程序运行的快的。
Java 通过 javac 命令将 Java 程序的源代码编译成 Java 字节码，即我们常说的 class 文件。这是我们通常意义上理解的编译。字节码并不是机器语言，要想让机器能够执行，还需要把字节码翻译成机器指令。这个过程是 Java 虚拟机做的，这个过程也叫编译。（实际上就是解释，引入 JIT 之后也存在编译）
Java 不完全是通过编译来生成机器码的，还结合了解释执行，那如何判断那些代码是使用编译执行还是解释执行呢？定义：当虚拟机发现某个方法或代码块的运行特别频繁时，就会把这些代码认定为“热点代码”。
HotSpot 使用第二种 - 基于计数器的热点探测方法。方法调用计数器触发即时编译的流程：计数器的种类（两种共同协作）了解了热点代码和计数器有什么用呢？即时编译是需要达到某种条件才会触发的。
解释器与编译器两者各有优势。解释器：当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。编译器：在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获取更高的执行效率。
HotSpot 虚拟机启用分层编译的策略。分层编译根据编译器编译、优化的规模与耗时，划分出不同的编译层次：实施分层编译后，Client Compiler 和 Server Compiler 将会同时工作，许多代码都可能会被多次编译看，用 Client Compiler 获取更高的编译速度，用 Server Compiler 获取更好的编译质量，在解释执行的时候也无须再承担收集性能监控信息的任务。
Java程序员有一个共识，以编译方式执行本地代码比解释方式更快，之所以有这样的共识，除去虚拟机解释执行字节码时额外消耗时间的原因外，还有一个很重要的原因就是虚拟机设计团队几乎把代码的所有优化措施都集中在了即时编译器之中，因此一般来说，即时编译器生成的本地代码比Javac产生的字节码更加优秀！
内联优化是：一是去除方法调用的成本（如建立栈帧等），二是为了其他优化建立良好的基础。方法的调用过程： (1) 首先会有个执行栈，存储目前所有活跃的方法，以及它们的本地变量和参数； (2) 当一个新的方法被调用了，一个新的栈帧会被加到当前线程的栈顶，分配的本地变量和参数会存储在这个栈帧中； (3) 跳到目标方法代码执行； (4) 方法返回的时候，本地方法和参数会被销毁，栈顶被移除； (5) 返回原来地址执行；
公共子表达式消除：如果一个表达式 E 已经计算过了，并且从先前的计算到现在 E 中所有变量的值都没有发生变化，那么 E 的这次出现就成为了公共子表达式！例如：int d = (c + b) * + a + (a + b * c);
Java语言是一门动态安全的语言。如果有一个数组 foo[]，在 Java 语言中访问数组元素 foo[i] 的时候系统将会自动进行上下界的范围检查，即检查 i 必须满足 i >=0 && i < foo.length 这个条件，否则将抛出一个运行时异常：java.lang.ArrayIndexOutOfBoundsException。
逃逸分析的基本行为就是分析对象动态作用域：当一个对象在方法中被定以后，它可能被外部方法所引用，例如作为调用参数传递到其他方法中，称为方法逃逸。甚至还有其可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问的实例变量，称为线程逃逸！
Java内存模型结构分为线程私有内存区：程序计数器、本地方法栈、虚拟机栈。线程共享内存区：Java 堆、方法区。对象实例化分析：这段代码的执行会涉及 Java 栈、Java 堆、方法区三个最重要的内存区域。假设该语句出现在方法体中，obj 会作为引用类型（reference）的数据保存在 Java 栈的本地变量表中，在 Java 堆中保存该引用的实例化对象。
从HotSpot源码，深度解读 park 和 unpark
我最近建立了一个在线自习室（App：番茄ToDO）用于相互监督学习，感兴趣的小伙伴可以加入。自习室加入码：D5A7A
Java并发包下的类大多基于AQS（AbstractQueuedSynchronizer）框架实现，而AQS线程安全的实现依赖于两个关键类：Unsafe和LockSupport。
其中，Unsafe主要提供CAS操作（关于CAS，在文章《读懂AtomicInteger源码（多线程专题）》中讲解过），LockSupport主要提供park/unpark操作。实际上，park/unpark操作的最终调用还是基于Unsafe类，因此Unsafe类才是核心。
Unsafe类的实现是由native关键字说明的，这意味着这个方法是原生函数，是用C/C++语言实现的，并被编译成了DLL，由Java去调用。
park函数的作用是将当前调用线程阻塞，而unpark函数则是唤醒指定线程。
park是等待一个许可，unpark是为某线程提供一个许可。如果线程A调用park，除非另一个线程调用unpark(A)给A一个许可，否则线程A将阻塞在park操作上。每次调用一次park，需要有一个unpark来解锁。
并且，unpark可以先于park调用，但不管unpark先调用多少次，都只提供一个许可，不可叠加。只需要一次park来消费掉unpark带来的许可，再次调用会阻塞。
在Linux系统下，park和unpark是通过Posix线程库pthread中的mutex（互斥量）和condition（条件变量）来实现的。
简单来说，mutex和condition保护了一个叫_counter的信号量。当park时，这个变量被设置为0，当unpark时，这个变量被设置为1。当_counter=0时线程阻塞，当_counter>0时直接设为0并返回。
每个Java线程都有一个Parker实例，Parker类的部分源码如下：
由源码可知，Parker类继承于PlatformParker，实际上是用Posix的mutex和condition来实现的。Parker类里的_counter字段，就是用来记录park和unpark是否需要阻塞的标识。
具体的执行逻辑已经用注释标记在代码中，简要来说，就是检查_counter是不是大于0，如果是，则把_counter设置为0，返回。如果等于零，继续执行，阻塞等待。
unpark直接设置_counter为1，再unlock mutex返回。如果_counter之前的值是0，则还要调用pthread_cond_signal唤醒在park中等待的线程。源码如下：
（如果不会下载JVM源码可以后台回复“jdk”，获得下载压缩包）
