java虚拟机

Posted 2021-02-14 三号小玩家

jvm简称java虚拟机。jvm使用软件模拟java字节码的指令集。

jvm规范：定义了

　　　　　　　　---Class文件类型

　　　　　　　　---运行时数据

　　　　　　　　---帧栈

　　　　　　　　----虚拟机的启动

　　　　　　　　----虚拟机的指令集

vm指令集：类型转换，出栈入栈操作，运算，流程控制，函数调用。

 

jvm需要对java Library提供以下支持：

--反射java.lang.reflect

--ClassLoader

--初始化class和interface

--安全相关 java.security

--多线程

--弱引用

 

 jvm编译：javap进行反汇编

 

jvm启动的流程：在当前路径和系统版本找jvm.cfg文件，根据配置找到JVM.dll，初始化JVM虚拟机获得JNIEnv接口，找到main方法开始运行。

jvm基本结构：

　　pc寄存器：

每个线程拥有一个pc寄存器。

在线程创建时创建。

指向下一条指令的地址。

执行本地方法时，pc的值为undefined。

 

方法区：

保存装载的类信息，通常和永久区关联在一起。

类型的常量池

字段，方法信息

方法字节码

 

java堆：

和程序开发密切相关，new出来的对象都在这里。

应用系统对象都保存在java堆中。

所有线程共享java堆。

对分代GC来说，堆也是分代的。

GC主要工作是区间。

 

java栈：

线程私有。

栈由一系列帧组成（因此栈也叫帧栈）

栈保存一个方法的局部变量，炒作数栈，常量池指针。

每一次方法调用创建一个帧，并压栈。

 栈上分配：

 

Java栈 – 栈上分配，只能分配小对象
小对象（一般几十个bytes），在没有逃逸的情况下，可以直接分配在栈上
直接分配在栈上，可以自动回收，减轻GC压力
大对象或者逃逸对象无法栈上分配

 内存模型：

每个线程有一个工作内存和主存独立

工作内存存放主存中变量值得拷贝

线程共享：

线程总是在自己的本地内存中存储变量，本地内存存储共享内存变量的一个副本，共享内存在主存当中的，共享变量存在时延和误差。

volatile 不能代替锁
一般认为volatile 比锁性能好（不绝对）

选择使用volatile的条件是：
语义是否满足应用

volatile 不是线程安全的

可见性
一个线程修改了变量，其他线程可以立即知道
保证可见性的方法
volatile
synchronized （unlock之前，写变量值回主存）
final(一旦初始化完成，其他线程就可见)

另外参考：http://www.cnblogs.com/43726581Gavin/p/9066080.html

有序性
在本线程内，操作都是有序的
在线程外观察，操作都是无序的。（指令重排 或 主内存同步延时）

指令重排
线程内串行语义
写后读    a = 1;b = a;    写一个变量之后，再读这个位置。
写后写    a = 1;a = 2;    写一个变量之后，再写这个变量。
读后写    a = b;b = 1;    读一个变量之后，再写这个变量。
以上语句不可重排，有依赖性的代码不可以重排
编译器不考虑多线程间的语义
可重排： a=1;b=2;

指令重排原则:

指令重排的基本原则
程序顺序原则：一个线程内保证语义的串行性
volatile规则：volatile变量的写，先发生于读
锁规则：解锁(unlock)必然发生在随后的加锁(lock)前
传递性：A先于B，B先于C 那么A必然先于C
线程的start方法先于它的每一个动作
线程的所有操作先于线程的终结（Thread.join()）
线程的中断（interrupt()）先于被中断线程的代码
对象的构造函数执行结束先于finalize()方法

解释运行
解释执行以解释方式运行字节码
解释执行的意思是：读一句执行一句
编译运行（JIT）
将字节码编译成机器码
直接执行机器码
运行时编译
编译后性能有数量级的提升

Java代码经过javac编译成class文件（字节码）

class（字节码）文件经过JVM编译成机器码进行解释执行（解释执行）

对于热点代码，JIT（JustInTime）编译器会在运行时将其编译为机器码执行（编译运行）

从上面我们可以看出，在JVM默认的mixed模式下JAVA既不完全是解释运行也不完全是编译运行。

 jvm参数设置：

-Xmx20m -Xms20m -Xmn15m  -XX:+PrintGCDetails -Xloggc:log/gc.log

设置jvm参数并且将参数输出到文件目录：

Java HotSpot(TM) 64-Bit Server VM (25.152-b16) for windows-amd64 JRE (1.8.0_152-b16), built on Sep 14 2017 02:29:36 by "java_re" with MS VC++ 10.0 (VS2010)
Memory: 4k page, physical 8281888k(3109468k free), swap 10247968k(3269608k free)
CommandLine flags: -XX:InitialHeapSize=20971520 -XX:MaxHeapSize=20971520 -XX:MaxNewSize=15728640 -XX:NewSize=15728640 -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC 
0.231: [GC (Allocation Failure) [PSYoungGen: 11527K->1528K(13824K)] 11527K->1760K(18944K), 0.0018172 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
Heap
 PSYoungGen      total 13824K, used 2800K [0x00000000ff100000, 0x0000000100000000, 0x0000000100000000)
  eden space 12288K, 10% used [0x00000000ff100000,0x00000000ff23e308,0x00000000ffd00000)
  from space 1536K, 99% used [0x00000000ffd00000,0x00000000ffe7e040,0x00000000ffe80000)
  to   space 1536K, 0% used [0x00000000ffe80000,0x00000000ffe80000,0x0000000100000000)
 ParOldGen       total 5120K, used 232K [0x00000000fec00000, 0x00000000ff100000, 0x00000000ff100000)
  object space 5120K, 4% used [0x00000000fec00000,0x00000000fec3a000,0x00000000ff100000)
 Metaspace       used 3436K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 373K, capacity 388K, committed 512K, reserved 1048576K

 

 

JVM中的新生代和老年代（Eden空间、两个Survior空间）