JVM总结
1.
1.别再说Java对象都是在堆内存上分配空间的了
JIT 技术
我们大家都知道，通过 javac 将可以将Java程序源代码编译，转换成 java 字节码，JVM 通过解释字节码将其翻译成对应的机器指令，逐条读入，逐条解释翻译。
这就是传统的JVM的解释器（Interpreter）的功能。
很显然，Java编译器经过解释执行，其执行速度必然会比直接执行可执行的二进制字节码慢很多。为了解决这种效率问题，引入了 JIT（Just In Time ，即时编译） 技术。
有了JIT技术之后，Java程序还是通过解释器进行解释执行，当JVM发现某个方法或代码块运行特别频繁的时候，就会认为这是“热点代码”（Hot Spot Code)。
然后JIT会把部分“热点代码”翻译成本地机器相关的机器码，并进行优化，然后再把翻译后的机器码缓存起来，以备下次使用。
2，jvm大局观之内存管理篇(二):当java中new一个对象,背后发生了什么
我们以最常用的虚拟机HotSpot和最常用的内存区域Java堆为例，深入探讨HotSpot虚拟机在Java堆中对象分配全过程。
一.类加载过程(类加载检查核定需要加载)
java是使用双亲委派模型来进行类的加载的，所以在描述类加载过程前，我们先看一下它的工作过程：
双亲委托模型的工作过程是：如果一个类加载器（ClassLoader）收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委托给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父类加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需要加载的类）时，子加载器才会尝试自己去加载。
使用双亲委托机制的好处是：能够有效确保一个类的全局唯一性，当程序中出现多个限定名相同的类时，类加载器在执行加载时，始终只会加载其中的某一个类。
1、加载
由类加载器负责根据一个类的全限定名来读取此类的二进制字节流到JVM内部，并存储在运行时内存区的方法区，然后将其转换为一个与目标类型对应的java.lang.Class对象实例
扩展: Class对象存储在堆区 99%的人都搞错了的java方法区存储内容,通过可视化工具HSDB和代码示例一次就弄明白了
2、验证
1.格式验证：验证是否符合class文件规范
2.语义验证：检查一个被标记为final的类型是否包含子类；检查一个类中的final方法是否被子3.类进行重写；确保父类和子类之间没有不兼容的一些方法声明（比如方法签名相同，但方法的返回值不同）
4.操作验证：在操作数栈中的数据必须进行正确的操作，对常量池中的各种符号引用执行验证（通常在解析阶段执行，检查是否可以通过符号引用中描述的全限定名定位到指定类型上，以及类成员信息的访问修饰符是否允许访问等）
对于虚拟机的类加载机制来说，验证阶段是一个重要的、但不是必要的阶段。
可以通过 -X verify:none参数来关闭大部分的类验证错失，以缩短虚拟机加载的时间, 提升程序启动时间
3、准备
为类中的所有静态变量分配内存空间，并为其设置一个初始值（由于还没有产生对象，实例变量不在此操作范围内）
被final修饰的static变量（常量），会直接赋值；
4、解析
将常量池中的符号引用转为直接引用（得到类或者字段、方法在内存中的指针或者偏移量，以便直接调用该方法），这个可以在初始化之后再执行。
解析需要静态绑定的内容。 // 所有不会被重写的方法和域都会被静态绑定
以上2、3、4三个阶段又合称为链接(Linking)阶段，链接阶段要做的是将加载到JVM中的二进制字节流的类数据信息合并到JVM的运行时状态中。
二. 为新生对象分配内存
在类加载检查通过后，接下来虚拟机将为新生对象分配内存。
对象所需内存的大小在类加载完成后便可完全确定，为对象分配空间的任务实际上便等同于把一块确定大小的内存块从Java堆中划分出来
优先在本地线程分配缓冲分配
除了如何划分可用空间外，在并发情况下划分不一定是线程安全的，有可能出现正在给A对象分配内存，指针还没有来得及修改，对象B又同时使用了原来的指针分配内存的情况，解决这个问题两种方案：
- 分配内存空间的动作进行同步处理：实际上虚拟机采用CAS配上失败重试的方式保证了更新操作的原子性。
- 内存分配的动作按照线程划分在不同的空间中进行：为每个线程在Java堆中预先分配一小块内存，称为本地线程分配缓冲（Thread Local Allocation Buffer, TLAB）。哪个线程要分配内存，就在哪个线程的本地缓冲区中分配，
- 只有本地缓冲区用完 了，分配新的缓存区时才需要同步锁定,虚拟机是否使用TLAB，可以通过-XX：+/-UseTLAB参数来设置
注意: 在jdk8中UseTLAB是默认开启的
2.1 如何分配到一块空闲的内存
2.1.1 指针碰撞分配 。假设Java堆中内存是绝对规整的，所有被使用过的内存都被放在一 边，空闲的内存被放在另一边，中间放着一个指针作为分界点的指示器，那所分配内存就仅仅是把那 个指针向空闲空间方向挪动一段与对象大小相等的距离，这种分配方式称为“指针碰撞”（Bump The Pointer）。
2.1.2 空闲列表分配
但如果Java堆中的内存并不是规整的，已被使用的内存和空闲的内存相互交错在一起，那 就没有办法简单地进行指针碰撞了，虚拟机就必须维护一个列表，记录上哪些内存块是可用的，在分 配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录，这种分配方式称 为“空闲列表”（Free List）
2.1.3 垃圾收集时是否带有空间压缩整理决定是上面两种分配方式中的一种
选择哪种分配方式由Java堆是否规整决定，而Java堆是否规整又由所采用 的垃圾收集器在收集时是否采用空间压缩整理（Compact）决定。 因此，当使用Serial、ParNew等带压缩整理过程的收集器时，系统采用的分配算法是指针碰撞，既简单又高效； 而当使用CMS这种基于清除（Sweep）算法的收集器时，理论上就只能采用较为复杂的空闲列表来分配内存。
注意: 后面的系列文章中我们会知道,实际上堆中,又会依据存活的对象生命周期被划分为年轻代和老年代,不同的代有不同的回收机制,一般来说年轻代中都是带有空间压缩整理的垃圾收集,所以jvm中大部分堆中的对象分配既有指针碰撞(Bump The Pointer),又有空闲列表
jvm大局观之内存管理篇(四):分代假说之下的java垃圾回收算法zhuanlan.zhihu.com
三. 新生对象各属性初始化零值
内存分配完成之后，虚拟机必须将分配到的内存空间（但不包括对象头）都初始化为零值,这步操作保证了对象的实例字段 在Java代码中可以不赋初始值就直接使用，使程序能访问到这些字段的数据类型所对应的零值
四. 设置新生对象的对象头
接下来，Java虚拟机还要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到 类的元数据信息、对象的哈希码（实际上对象的哈希码会延后到真正调用Object::hashCode()方法时才 计算）、对象的GC分代年龄等信息。这些信息存放在对象的对象头（Object Header）之中。
五. 为新生对象执行init方法
在上面工作都完成之后，从虚拟机的视角来看，一个新的对象已经产生了。
但是从Java程序的视角看来，对象创建才刚刚开始——构造函数，即Class文件中的()方法还没有执行，所有的字段都为默认的零值，对象需要的其他资源和状态信息也还没有按照预定的意图构造好。
一般来说new指令之后会接着执行 ()方法，按照程序员的意愿对对象进行初始化，这样一个真正可用的对象才算完全被构造出来。
发散: 当对象创建完成之后,指向这个对象的引用,一定是存储在栈区吗? 如果不是, 为什么? 如果有读者感兴趣,在评论区说明,会在后续继续更新文章
不是的。栈主要负责方法的调用。也就是说，只有方法执行的过程中涉及到的引用才会被装载到栈上，具体位置是当前线程的栈中的局部变量表。这些引用主要有局部变量，方法参数。而引用还包括堆中对象对其他对象的引用，这些引用在未被使用时不会装到栈中。
扩展
扩展1:new对象过程案例:
Student类代码如下
public class Student {
private String name = "林青霞";
private int age = 27;
public Student() {
name = "刘意";
age = 30;
}
}
class StudentDemo {
public static void main(String[] args) {
Student s = new Student();
}
}
Student s = new Student()做了哪些事情?
1、把Student. class文件加载到内存
2、在栈内存给s变量开辟一个空间
3、在堆内存为学生对象申请一个空间
4、给成员变量进行默认初始化。null,0
5、给成员变量进行显示初始化。林青霞，27
6、通过构造方法给成员变量进行初始化。刘意，30
7、数据初始化完毕，然后把堆内存的地址值赋值给栈内存的s变量。
扩展2: 创建对象指令重排序问题:
new一个对象的简单分解动作
- 分配对象的内存空间
- 初始化对象
- 设置引用指向分配的内存地址
其中2和3两步间会发生指令重排序，导致多线程时，如果在初始化之前访问对象，则会出现问题，单例模式的双重检测锁模式(DCL double check lock)正是会存在这个问题。可以使用volatile来禁止指令重排序解决问题
先看如下代码：
public static Singleton getInstance(){
if(instance == null){
synchronized(Singleton.class){
if(instance==null)
instance = new Singleton();
}
}
return instance;
}
这部分代码首先判断instance是否为null，如果为null，则进入一个synchronize包围的代码块，上了锁，进入了临界区，为了防止在判断为null到进入临界区的过程中，有线程对其new了一个实例出来，再上锁完成之后，在对instance是否为null进行一次判断，如果这次还是为null，则可以确认确实instance为null，并且此时也不会有其他线程尝试new一个instance出来，因此可以放心地执行new对象的工作。
这个代码在单线程的环境下是没错的，但是如果在并发的环境下，会出现严重的问题。
问题其实出在java的编译器上，java的编译器会将字节码命令进行重排序以便进行优化，在第五行，构造函数的调用应该在instance得到赋值之前发生，但是在java虚拟机内部，却不是这样的，完全有可能先new出来一个空的未调用过构造函数的instance对象，然后再将其赋值给instance引用，然后再调用构造函数，对instance对象当中的元素进行初始化。
这样，就很有可能，当instance被赋值一个空的实例对象的时候，另一个线程调用了getInstance（）这个函数，另一个线程发现，instance并不是空的，于是愉快地return回了那个空的instance对象。这样，一个空的instance对象的引用就被流传到了其他线程当中，为非作歹。
为什么会出现部分构造的对象
简单来说是因为无序写入（out-of-order writes）。
如果构造函数写入非 final 字段，则不必立即将它们提交到内存，甚至可以在单例变量之后提交。构造函数其实已经完成，但这并不意味着所有写入对其它线程可见。
部分构造就是这种情况的一个糟糕体现，singleInstance 引用已对其它线程可见，但对象的内容singleInstance.getId() 对其它线程并不可见。就是因为对象构造过程中一系列指令写入内存的乱序，导致了失效对象的产生。
解决方法
在 Java 5.0 之后，使用 volatile 来修饰 singleInstance 实例，就不会产生指令重排序的情况，这样 DCL(double check lock) 也就可以正常工作了。
private volatile Singleton instance;
public static Singleton getInstance(){
if(instance == null){
synchronized(Singleton.class){
if(instance==null)
instance = new Singleton();
}
}
return instance;
}
但因为有了更加方便与安全的替代方式，DCL 也没有什么特别的优势，便被废弃了。
延迟初始化占位类模式
使用延迟初始化占位类模式，可以在保证延迟加载优点的同时，得到 Java 语言层面提供的安全保障。当然也包括 Java 内存模型相关，可以了解到更多 out-of-order writes 相关的原理。
也就是如下所示
public class ResouceFactory {
public static Resource resource= new Resource();
public static Resource getInstance() {
return resource;
}
}
因为在初始化器中采用了特殊的方式处理静态域，并提供了额外的线程安全性保证。静态初始化器是由JVM在类的初始化阶段执行，即在类被加载后并且被线程使用之前。由于JVM在初始化期间将获得一个锁，且每个线程都至少获取一次这个锁以确保这个类已经加载，故在静态初始化期间，内存写入操作将自动对所有的线程可见，以及避免数据破坏。
简言之，类中的静态变量在声明的时候就做初始化，可以经由JVM提供线程安全方便的保证，而无需自己添加synchronized关键字去进行同步，从而减少了线程同步带来的性能消耗。这种初始化方式被称为提前初始化。相对的，之前两种初始化方式，被称为惰性初始化或者延迟初始化。
考虑到有些类的实例在初始化的时候，可能会产生比较高的开销，故人们希望在需要用到的时候再进行初始化，于是结合延迟初始化域JVM初始化静态域的特点，产生了较为常用的延迟初始化占位类模式：
public class ResouceFactory {
private static class ResourceHolder {
public static Resource resource = new Resource();
}
public static Resource getInstance() {
return ResourceHolder.resource;
}
}因为静态类在使用的时候才会被加载，故JVM第一次加载该静态类的时候，通过JVM即可实现静态域的线程同步，即满足了延迟加载的需求，也避开了同步带来的性能消耗。
