Ethan_199402的博客

zgc,g1,cms对比

Jps：Java Virtual Machine Process Status Tooljps是用于查看有权访问的hotspot虚拟机的进程. 当未指定hostid时，默认查看本机jvm进程，否者查看指定的hostid机器上的jvm进程，此时hostid所指机器必须开启jstatd服务。 jps可以列出jvm进程lvmid，主类类名，main函数参数, jvm参数，jar名称等信息。命令用法：使用jps -help输出如下-q 只显示pid，不显示class名称,jar文件名和传递给main方法的

JVM在进行Gc时，并非每次都对新生代、老年代、方法区一起回收的,大部分时候回收的都是指新生代。概述针对HotSpot VM的实现，它里面的GC按照回收区域又分为两大种类型:一种是部分收集(Partial GC）,一种是整堆收集（Full GC)部分收集:不是完整收集整个Java堆的垃圾收集。其中又分为:1）新生代收集（Minor GC / Young Gc）:只是新生代的垃圾收集2）老年代收集（Major Gc / old GC):只是老年代的垃圾收集。目前,只有CMS GC会有单独收集老年

我们已经从JVM（一） 面试必知——运行时数据区域了解到Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。本篇详解Java虚拟机栈相关内容运行时栈帧结构Java虚拟机以方法作为最基本的执行单元，“栈帧”（Stack Frame）则是用于支持虚拟机进行方法 调用和方法执行背后的数据结构，它也是虚拟机运行时数据区中的虚拟机栈（Virtual Machine Stack）的栈元素。每 一个方法从调用开始至执行结束的过程，都对应着一个栈帧在虚拟机栈里面从入栈到出栈的过程

类加载机制大致分为5个阶段：（1）加载：java类运行时候会生成一个class字节码文件，加载的过程就是去我们的操作系统寻找这个class文件。（2）链接：这个过程就是把class文件加载到java虚拟机。（3）初始化：在虚拟机中根据class文件进行初始化。（4）使用：这个过程大家都明白。（5）卸载：使用完了，java虚拟机进行清理。对于class.forName和classloader来说针对的就是第一个过程，也就是加载过程。不过这俩虽然有一定的相似性，但是区别还是挺大的。详情可看另一边

什么是字符串常量池string的string Pool是一个圉定大小的Hashtable，默认值大小长度是1009。如果放进string Pool的string非常多，就会造成Hash冲突严重，从而导致链表会很长，而链表长了后直接会造成的影响就是当调用string.intern时性能会大幅下降。参数设置使用-xX :StringTablesize可设置stringTable的长度在jdk6中stringTable是固定的，就是1009的长度，所以如果常量池中的字符串过多就会导致效率下降很快。Stri

我们已经在[JVM （六） Class类文件的结构](https://blog.csdn.net/Ethan_199402/article/details/110858799)学习了Class文件存储格式的具体细节，在Class文件中描述的各类信息，最终都需要加 载到虚拟机中之后才能被运行和使用。而虚拟机如何加载这些Class文件，Class文件中的信息进入到虚 拟机后会发生什么变化，这些都是本文将要讲解的内容

类加载的应用

范德萨

Java语言定义了6种线程状态，在任意一个时间点中，一个线程只能有且只有其中的一种状态，并 且可以通过特定的方法在不同状态之间转换。这6种状态分别是：·新建（New）：创建后尚未启动的线程处于这种状态。·运行（Runnable）：包括操作系统线程状态中的Running和Ready，也就是处于此状态的线程有可 能正在执行，也有可能正在等待着操作系统为它分配执行时间。·无限期等待（Waiting）：处于这种状态的线程不会被分配处理器执行时间，它们要等待被其他线 程显式唤醒。以下方法会让线程陷入无限期的

回顾在《并发高级之详解volatile——你看到了多少假象》一文中我们已经对volatile有一个具体的了解，首先回顾一下可见性如何实现：当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效，线程接下来将会从主内存中读取共享变量然后是有序性的实现：Memory Barrier 可以保证内存可见性和特定操作的执行顺序volatile写操作之后都会插入一个store屏障，将工作内存中的值刷回到主内

基本介绍尽 管不同版本的《Java虚拟机规范》对Class文件格式进行了几次更新，但基本上只是在原有结构基础上 新增内容、扩充功能，并未对已定义的内容做出修改。Class文件是一组以8个字节为基础单位的二进制流，各个数据项目严格按照顺序紧凑地排列在文 件之中，中间没有添加任何分隔符，这使得整个Class文件中存储的内容几乎全部是程序运行的必要数 据，没有空隙存在。当遇到需要占用8个字节以上空间的数据项时，则会按照高位在前的方式分割 成若干个8个字节进行存储Class文件格式采用一种类似于C语言结构体

随着JDK8的到来，JVM不再有PermGen。但类的元数据信息（metadata）还在，只不过不再是存储在连续的堆空间上，而是移动到叫做“Metaspace”的本地内存（Native memory）中。从上图可以看到，元空间和直接内存都是堆外内存，那么二者的区别是什么呢？元空间：DK1.8以前的HotSpot JVM有方法区，也叫永久代(permanent generation)。（永久代是针对hotspot虚拟机来说的）方法区用于存放已被虚拟机加载的类信息、常量、静态变量，即编译器编译后的代码。

Java技术体系的自动内存管理，最根本的目标是自动化地解决两个问题：自动给对象分配内存以 及自动回收分配给对象的内存。关于回收内存这方面，之前的文章已经通过介绍虚拟机中的垃 圾收集器体系以及运作原理来有了较为深入的认识，现在我们来探讨一下关于给对象分配内存的那些事儿在经典分代的设计下，新生对象通常会分配在新生代中，少数 情况下（例如对象大小超过一定阈值）也可能会直接分配在老年代。对象分配的规则并不是固定的， 《Java虚拟机规范》并未规定新对象的创建和存储细节，这取决于虚拟机当前使用的是哪一种垃圾收 集器

上一篇文章已经介绍完最初的几款经典垃圾收集器，其中多次提到CMS收集器，接下来重点介绍CMS和Garbage First（简称G1）垃圾收集器CMS收集器CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很 大一部分的Java应用集中在互联网网站或者基于浏览器的B/S系统的服务端上，这类应用通常都会较为 关注服务的响应速度，希望系统停顿时间尽可能短，以给用户带来良好的交互体验。CMS收集器就非 常符合这类应用的需求。运作过程从名字（包含“M

HotSpot虚拟机开发团队为消除或者降低用户线程因 垃圾收集而导致停顿的努力一直持续进行着，从Serial收集器到Parallel收集器，再到Concurrent Mark Sweep（CMS）和Garbage First（G1）收集器，最终至现在垃圾收集器的最前沿成果Shenandoah和ZGC 等，我们看到了一个个越来越构思精巧，越来越优秀，也越来越复杂的垃圾收集器不断涌现，用户线 程的停顿时间在持续缩短，但是仍然没有办法彻底消除（这里不去讨论RTSJ中的收集器），探索更优 秀垃圾收集器的工作仍在继续

一 怎么判断对象已死？1 引用计数算法引用计数法是经典的，而经典有时候又意味这过时很多教科书判断对象是否存活的算法是这样的：在对象中添加一个引用计数器，每当有一个地方 引用它时，计数器值就加一；当引用失效时，计数器值就减一；任何时刻计数器为零的对象就是不可 能再被使用的客观地说，引用计数算法（Reference Counting）虽然占用了一些额外的内存空间来进行计数，但 它的原理简单，判定效率也很高，在大多数情况下它都是一个不错的算法。也有一些比较著名的应用 案例，例如微软COM（Componen

        Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。        这些区域 有各自的用途，以及创建和销毁的时间，有的区域随着虚拟机进程的启动而一直存在，有些区域则是 依赖用户线程的启动和结束而建立和销毁。根据《Java虚拟机规范》的规定，Java虚拟机所管理的内存 将会包括以下几个运行时数据区域