技术分享之JVM Basics And JVM Troubleshooting

1. 类加载器子系统主要用于定位类定义的二进制信息，然后将这些信息解析并加载至虚拟机，转化为虚拟机内部的类型信息的数据结构。类加载器子系统还承担着安全性的责任，并且是JVM的动态链接和动态加载的基础。将二进制信息=>类型信息的数据结构，首先类加载器是JVM安全沙箱的第一道防线，能够防止非信任类破坏虚拟机。类加载器在方法区构造具有这个类的信息的数据结构后，会在堆上创建一个Class对象作为访问这个数据结构的接口。同时，类加载还需要初始化类的静态数据，也就是调用类的 方法。以上就是一个类的加载、链接及初始化的过程。 2. 运行时数据区是JVM运行时的内存空间的组织，逻辑上又划分为多个区，这些区的生命周期和它是否线程共享有关，它们分别是：         堆：用于存放对象或数组实例，也就是运行期间new出来的对象。堆的生命周期与JVM相同，并且在线程之间共享访问。由于多线程并发访问，所以需要考虑线程安全的问题，有两种方法。第一种是，加锁进行互斥访问。第二种是线程本地分配缓冲(Thread Local Allocate Buffer， TLAB)，在线程创建时预先给每个线程分配一块区域，这块区域是线程私有的，对其他线程是不可见，也就不会被共享。JVM规范规定在申请不到足够的内存时，堆会抛出OutOfMemoryException。         方法区：存放类型信息和运行时常量池(Runtime Constant Pool)。每个被类加载器加载的类都会在方法区中形成一个与子对应的类型信息的数据结构，包括：这个类的类名、直接超类、实现的接口列表、字段列表、方法列表等。运行时常量池是class文件中的常量池列表(Constant Pool List)在运行时的一种体现，其中存储各种基本数据类型及String类型的常量以及其他类、方法、字段的符号引用。方法区的生命周期与JVM相同，被多个线程共享，所以要考虑并发访问的安全性的问题。JVM规范规定在需要的内存得不到满足的情况下，方法区会抛出OutOfMemoryException。         PC(Program Counter)：线程私有的，生命周期与线程相同，是对CPU中PC的一种模拟。如果线程正在执行的是 Java 方法，则该线程的PC中存放的下一条字节码指令的地址。在进行Java方法的调用和返回时，需要更新PC以保存当前方法(Current Method)正在执行的字节码指令的地址。PC是JVM规范中唯一没有规定会抛出异常的存储区。         JVM栈：线程私有，生命周期与线程相同，是对传统语言(比如C)中的方法调用栈的一种模拟。JVM栈中存放栈帧(Frame)用于进行方法调用和返回、存储局部变量以及计算的中间结果。JVM规范规定栈可以抛出两种异常：（1）StackOverflowException，在栈的深度大于某个规定值的情况下抛出。（2）OutOfMemoryException，在为新栈帧分配内存或者是为线程分配栈的内存时，申请不到足够的内存的情况下抛出。         JVM栈中存放的是栈帧，每个栈帧对应着一次方法调用。每一时刻，JVM线程只能执行一个方法(Current Method)，该方法的栈帧是JVM栈的栈顶的元素(叫做当前栈帧，Current Frame)，当调用一个方法时，会初始化一个栈帧压入JVM栈；当方法调用返回或者抛出异常没有被处理的情况下，JVM栈会弹出该方法对应的栈帧。每一个栈帧中存放局部变量表(Local Variable Table)、操作数栈(Oprand Stack)以及其他栈帧信息。栈帧的大小在编译时就确定了，编译器会把局部变量表和操作数栈的大小记录在class文件中method_info的属性表中。局部变量表类似于数组存放局部变量和方法参数。由于JVM采用的是基于栈的指令集体系结构，而不是基于寄存器，所以JVM上的所有计算都是在操作数栈上进行的(比如，算术运算、方法调用、内存访问等)。         本地方法栈：用于支持本地方法调用，抛出的异常与JVM栈相同。 3. 执行引擎用于执行JVM字节码指令，主要由两种实现方式：（1）将输入的字节码指令在加载时或执行时翻译成另外一种虚拟机指令；（2）将输入的字节码指令在加载时或执行时翻译成宿主主机本地CPU的指令集。这两种方式对应着字节码的解释执行和即时编译。比如在HotSpot VM中执行引擎的实现是一种解释-编译的层次结构：         （1）解释执行：解释执行字节码，并以方法为单位收集“热点(HotSpot)代码”的信息，将“热点代码”执行C0编译。         （2）C0编译：将收集的“热点代码”编译成本地代码，并进行一些简单的优化。继续收集运行时信息，将一些频繁执行的本地代码进行C1编译。         （3）C1编译：将C0阶段的本地代码，进行一些比较激进的优化。如果某些优化导致本地代码执行失败，此时JVM会退化到解释执行字节码阶段。

目前的32位系统分页大小为4K，寻址位宽为32位，因此，第0个分页的地址是0x00000000，第1个分页地址从0x00001000开始，以此类推。所以，在目前的32位系统中，用到了32位中的高20位来标记物理页，剩余的12位用于添加一些标记信息等。这样，就可以支持到最大(2^20)*4096=4GB内存

1. 引用计数法 (Reference Counting) 引用计数器的实现很简单，对于一个对象 A，只要有任何一个对象引用了 A，则 A 的引用计数器就加 1，当引用失效时，引用计数器就减 1。只要对象 A 的引用计数器的值为 0，则对象 A 就不可能再被使用。 引用计数器的实现也非常简单，只需要为每个对象配置一个整形的计数器即可。但是引用计数器有一个严重的问题，即无法处理循环引用的情况。因此，在 Java 的垃圾回收器中没有使用这种算法。 GC Roots对象包括： a) 虚拟机栈（栈帧中的本地变量表）中的引用的对象。 b) 方法区域中的类静态属性引用的对象。 c) 方法区域中常量引用的对象。 d) 本地方法栈中JNI（Native方法）的引用的对象。 2. 标记-清除算法 (Mark-Sweep) 标记-清除算法将垃圾回收分为两个阶段：标记阶段和清除阶段。一种可行的实现是，在标记阶段首先通过根节点，标记所有从根节点开始的较大对象。因此，未被标记的对象就是未被引用的垃圾对象。然后，在清除阶段，清除所有未被标记的对象。该算法最大的问题是存在大量的空间碎片，因为回收后的空间是不连续的。在对象的堆空间分配过程中，尤其是大对象的内存分配，不连续的内存空间的工作效率要低于连续的空间。 3. 复制算法 (Copying) 将现有的内存空间分为两快，每次只使用其中一块，在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中，之后，清除正在使用的内存块中的所有对象，交换两个内存的角色，完成垃圾回收。 如果系统中的垃圾对象很多，复制算法需要复制的存活对象数量并不会太大。因此在真正需要垃圾回收的时刻，复制算法的效率是很高的。又由于对象在垃圾回收过程中统一被复制到新的内存空间中，因此，可确保回收后的内存空间是没有碎片的。该算法的缺点是将系统内存折半。 Java 的新生代串行垃圾回收器中使用了复制算法的思想。新生代分为 eden 空间、from 空间、to 空间 3 个部分。其中 from 空间和 to 空间可以视为用于复制的两块大小相同、地位相等，且可进行角色互换的空间块。from 和 to 空间也称为 survivor 空间，即幸存者空间，用于存放未被回收的对象。 在垃圾回收时，eden 空间中的存活对象会被复制到未使用的 survivor 空间中 (假设是 to)，正在使用的 survivor 空间 (假设是 from) 中的年轻对象也会被复制到 to 空间中 (大对象，或者老年对象会直接进入老年带，如果 to 空间已满，则对象也会直接进入老年代)。此时，eden 空间和 from 空间中的剩余对象就是垃圾对象，可以直接清空，to 空间则存放此次回收后的存活对象。这种改进的复制算法既保证了空间的连续性，又避免了大量的内存空间浪费。 4. 标记-压缩算法 (Mark-Compact) 复制算法的高效性是建立在存活对象少、垃圾对象多的前提下的。这种情况在年轻代经常发生，但是在老年代更常见的情况是大部分对象都是存活对象。如果依然使用复制算法，由于存活的对象较多，复制的成本也将很高。 标记-压缩算法是一种老年代的回收算法，它在标记-清除算法的基础上做了一些优化。也首先需要从根节点开始对所有可达对象做一次标记，但之后，它并不简单地清理未标记的对象，而是将所有的存活对象压缩到内存的一端。之后，清理边界外所有的空间。这种方法既避免了碎片的产生，又不需要两块相同的内存空间，因此，其性价比比较高。 5. 增量算法 (Incremental Collecting) 在垃圾回收过程中，应用软件将处于一种 CPU 消耗很高的状态。在这种 CPU 消耗很高的状态下，应用程序所有的线程都会挂起，暂停一切正常的工作，等待垃圾回收的完成。如果垃圾回收时间过长，应用程序会被挂起很久，将严重影响用户体验或者系统的稳定性。 增量算法的基本思想是，如果一次性将所有的垃圾进行处理，需要造成系统长时间的停顿，那么就可以让垃圾收集线程和应用程序线程交替执行。每次，垃圾收集线程只收集一小片区域的内存空间，接着切换到应用程序线程。依次反复，直到垃圾收集完成。使用这种方式，由于在垃圾回收过程中，间断性地还执行了应用程序代码，所以能减少系统的停顿时间。但是，因为线程切换和上下文转换的消耗，会使得垃圾回收的总体成本上升，造成系统吞吐量的下降。 6. 分代 (Generational Collecting) 根据垃圾回收对象的特性，不同阶段最优的方式是使用合适的算法用于本阶段的垃圾回收，分代算法即是基于这种思想，它将内存区间根据对象的特点分成几块，根据每块内存区间的特点，使用不同的回收算法，以提高垃圾回收的效率。以 Hot Spot 虚拟机为例，它将所有的新建对象都放入称为年轻代的内存区域，年轻代的特点是对象会很快回收，因此，在年轻代就选择效率较高的复制算法。当一个对象经过几次回收后依然存活，对象就会被放入称为老生代的内存空间。在老生代中，几乎所有的对象都是经过几次垃圾回收后依然得以幸存的。因此，可以认为这些对象在一段时期内，甚至在应用程序的整个生命周期中，将是常驻内存的。如果依然使用复制算法回收老生代，将需要复制大量对象。再加上老生代的回收性价比也要低于新生代，因此这种做法也是不可取的。根据分代的思想，可以对老年代的回收使用与新生代不同的标记-压缩算法，以提高垃圾回收效率。

1. 新生代串行收集器 串行收集器主要有两个特点：第一，它仅仅使用单线程进行垃圾回收；第二，它独占式的垃圾回收。 2. 老年代串行收集器 老年代串行收集器使用的是标记-压缩算法。和新生代串行收集器一样，它也是一个串行的、独占式的垃圾回收器。由于老年代垃圾回收通常会使用比新生代垃圾回收更长的时间，因此，在堆空间较大的应用程序中，一旦老年代串行收集器启动，应用程序很可能会因此停顿几秒甚至更长时间。虽然如此，老年代串行回收器可以和多种新生代回收器配合使用，同时它也可以作为 CMS 回收器的备用回收器。 3. 并行收集器 并行收集器是工作在新生代的垃圾收集器，它只简单地将串行回收器多线程化。它的回收策略、算法以及参数和串行回收器一样。 并行回收器也是独占式的回收器，在收集过程中，应用程序会全部暂停。但由于并行回收器使用多线程进行垃圾回收，因此，在并发能力比较强的 CPU 上，它产生的停顿时间要短于串行回收器，而在单 CPU 或者并发能力较弱的系统中，并行回收器的效果不会比串行回收器好，由于多线程的压力，它的实际表现很可能比串行回收器差。 4.新生代并行回收 (Parallel Scavenge) 收集器 新生代并行回收收集器也是使用复制算法的收集器。从表面上看，它和并行收集器一样都是多线程、独占式的收集器。但是，并行回收收集器有一个重要的特点：它非常关注系统的吞吐量。 新生代并行回收收集器可以使用以下参数启用： -XX:+UseParallelGC:新生代使用并行回收收集器，老年代使用串行收集器。 -XX:+UseParallelOldGC:新生代和老年代都是用并行回收收集器。 5. 老年代并行回收收集器 老年代的并行回收收集器也是一种多线程并发的收集器。和新生代并行回收收集器一样，它也是一种关注吞吐量的收集器。老年代并行回收收集器使用标记-压缩算法，JDK1.6 之后开始启用。 使用-XX:+UseParallelOldGC 可以在新生代和老生代都使用并行回收收集器，这是一对非常关注吞吐量的垃圾收集器组合，在对吞吐量敏感的系统中，可以考虑使用。参数-XX:ParallelGCThreads 也可以用于设置垃圾回收时的线程数量。 6. CMS 收集器 与并行回收收集器不同，CMS 收集器主要关注于系统停顿时间。CMS 是 Concurrent Mark Sweep 的缩写，意为并发标记清除，从名称上可以得知，它使用的是标记-清除算法，同时它又是一个使用多线程并发回收的垃圾收集器。 CMS 工作时，主要步骤有：初始标记、并发标记、重新标记、并发清除和并发重置。其中初始标记和重新标记是独占系统资源的，而并发标记、并发清除和并发重置是可以和用户线程一起执行的。因此，从整体上来说，CMS 收集不是独占式的，它可以在应用程序运行过程中进行垃圾回收。 根据标记-清除算法，初始标记、并发标记和重新标记都是为了标记出需要回收的对象。并发清理则是在标记完成后，正式回收垃圾对象；并发重置是指在垃圾回收完成后，重新初始化 CMS 数据结构和数据，为下一次垃圾回收做好准备。并发标记、并发清理和并发重置都是可以和应用程序线程一起执行的。 CMS 收集器在其主要的工作阶段虽然没有暴力地彻底暂停应用程序线程，但是由于它和应用程序线程并发执行，相互抢占 CPU，所以在 CMS 执行期内对应用程序吞吐量造成一定影响。CMS 默认启动的线程数是 (ParallelGCThreads+3)/4),ParallelGCThreads 是新生代并行收集器的线程数，也可以通过-XX:ParallelCMSThreads 参数手工设定 CMS 的线程数量。当 CPU 资源比较紧张时，受到 CMS 收集器线程的影响，应用程序的性能在垃圾回收阶段可能会非常糟糕。 由于 CMS 收集器不是独占式的回收器，在 CMS 回收过程中，应用程序仍然在不停地工作。在应用程序工作过程中，又会不断地产生垃圾。这些新生成的垃圾在当前 CMS 回收过程中是无法清除的。同时，因为应用程序没有中断，所以在 CMS 回收过程中，还应该确保应用程序有足够的内存可用。因此，CMS 收集器不会等待堆内存饱和时才进行垃圾回收，而是当前堆内存使用率达到某一阈值时，便开始进行回收，以确保应用程序在 CMS 工作过程中依然有足够的空间支持应用程序运行。 G1 收集器 (Garbage First) G1 收集器的目标是作为一款服务器的垃圾收集器，因此，它在吞吐量和停顿控制上，预期要优于 CMS 收集器。 与 CMS 收集器相比，G1 收集器是基于标记-压缩算法的。因此，它不会产生空间碎片，也没有必要在收集完成后，进行一次独占式的碎片整理工作。G1 收集器还可以进行非常精确的停顿控制。它可以让开发人员指定当停顿时长为 M 时，垃圾回收时间不超过 N。使用参数-XX:+UnlockExperimentalVMOptions –XX:+UseG1GC 来启用 G1 回收器，设置 G1 回收器的目标停顿时间：-XX:MaxGCPauseMills=20,-XX:GCPauseIntervalMills=200。

Minor GC vs Major GC vs Full GC Minor GC 从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC。这一定义既清晰又易于理解。但是，当发生Minor GC事件的时候，有一些有趣的地方需要注意到： 1. 当 JVM 无法为一个新的对象分配空间时会触发 Minor GC，比如当 Eden 区满了。所以分配率越高，越频繁执行 Minor GC。 2. 内存池被填满的时候，其中的内容全部会被复制，指针会从0开始跟踪空闲内存。Eden 和 Survivor 区进行了标记和复制操作，取代了经典的标记、扫描、压缩、清理操作。所以 Eden 和 Survivor 区不存在内存碎片。写指针总是停留在所使用内存池的顶部。 3. 执行 Minor GC 操作时，不会影响到永久代。从永久代到年轻代的引用被当成 GC roots，从年轻代到永久代的引用在标记阶段被直接忽略掉。 4. 质疑常规的认知，所有的 Minor GC 都会触发“全世界的暂停（stop-the-world）”，停止应用程序的线程。对于大部分应用程序，停顿导致的延迟都是可以忽略不计的。其中的真相就 是，大部分 Eden 区中的对象都能被认为是垃圾，永远也不会被复制到 Survivor 区或者老年代空间。如果正好相反，Eden 区大部分新生对象不符合 GC 条件，Minor GC 执行时暂停的时间将会长很多。 Major GC 是清理老年代。 Full GC 是清理整个堆空间—包括年轻代和老年代 许多 Major GC 是由 Minor GC 触发的，所以很多情况下将这两种 GC 分离是不太可能的 这使得我们不用去关心到底是叫 Major GC 还是 Full GC，大家应该关注当前的 GC 是否停止了所有应用程序的线程，还是能够并发的处理而不用停掉应用程序的线程 http://www.importnew.com/15820.html

（1）目前的收益，调整过这几种gc回收器，但是效果不大，采用java8默认的目前来看比较合适 （1）目前吞吐量小，差别不大 （2）回收器参数需要根据业务细调 (2) 为什么heap size<=3G下不建议采用CMS GC？(http://hellojava.info/?p=142) 可以用以下指标评价一个垃圾处理器的好坏。 吞吐量：指在应用程序的生命周期内，应用程序所花费的时间和系统总运行时间的比值。系统总运行时间=应用程序耗时+GC 耗时。如果系统运行了 100min，GC 耗时 1min，那么系统的吞吐量就是 (100-1)/100=99%。 垃圾回收器负载：和吞吐量相反，垃圾回收器负载指来记回收器耗时与系统运行总时间的比值。 停顿时间：指垃圾回收器正在运行时，应用程序的暂停时间。对于独占回收器而言，停顿时间可能会比较长。使用并发的回收器时，由于垃圾回收器和应用程序交替运行，程序的停顿时间会变短，但是，由于其效率很可能不如独占垃圾回收器，故系统的吞吐量可能会较低。 垃圾回收频率：指垃圾回收器多长时间会运行一次。一般来说，对于固定的应用而言，垃圾回收器的频率应该是越低越好。通常增大堆空间可以有效降低垃圾回收发生的频率，但是可能会增加回收产生的停顿时间。 反应时间：指当一个对象被称为垃圾后多长时间内，它所占据的内存空间会被释放。 堆分配：不同的垃圾回收器对堆内存的分配方式可能是不同的。一个良好的垃圾收集器应该有一个合理的堆内存区间划分。

jstat [option vmid [interval[s|ms] [count]] ] — jstat -gc 5828 250 5 jinfo [option] pid jmap（Memory Map for Java）命令用于生产堆转储快照（一般称为heapdump或dump文件）。如果不使用jmap命令，要向获取Java堆转储快照还有一些比较”暴力“的手段：譬如-XX:+HeapDumpOnOutOfMemoryError参数，可以让虚拟机在OOM异常出现之后自动生生成dump文件，通过-XX:+HeapDumpOnCtrlBreak参数则可以使用[Ctrl]+[Break]键让虚拟机生成dump文件，又或者在 Linux 系统下通过Kill -3命令发送进程退出信号”恐吓“一下虚拟机，也能拿到dump文件。 还有强制进行一次full GC的“副作用” jstack（Stack Trace for Java）命令用于生成虚拟机当前时刻的线程快照（一般称为threaddump或javacore文件）。线程快照就是当前虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等都是导致线程长时间停顿的常见原因。线程出现停顿的时候通过jstack来查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做些什么事情，或者等待着什么资源。 jstack，线程堆栈打印。注意waiting to lock 在等待锁，比如进入临界区时；locked 表示当前同步操作，线程锁住了某资源；而waiting on 指的是在同步块内，wait方法的执行中暂时地释放了该锁的占用，等唤醒的时候需要重新获取

BTrace就是一个可以在不改代码、不重启应用的情况下，动态的查看程序运行细节的工具，其官方网站在此：http://kenai.com/projects/btrace/,例子：http://jm.taobao.org/2010/11/11/509/

Es启动检查 too many open files

linux在2.6.32内核以后支持了高精度的调度，在.32以前的内核里，即使你在java里写queue.await(1ns)之类的代码，其实都是需要1ms左右才会执行的，但.32以后则可以支持ns级的调度，对于实时性要求非常非常高的性能而言，这本来是个好特性。 但不幸的是很多人在写代码的时候其实压根就没有要ns级调度的需求，纯粹只是随便写了一个类似10ns唤醒的策略，这个在内核升级到.32后就悲催了，直接就会看到cpu sy猛增，很容易以为是内核的bug，话说其实这可以认为是程序本身的bug

Suggestion索引好几个hs_err_pid.log When the Java Virtual Machine starts, by default it spawns a number of Garbage Collection (GC) threads, which are used for parallel GC operations … the number of such threads is calculated by this formula: (ncpus<= 8) ? ncpus : 3 + ((ncpus * 5) / 8) … Because of the creation of these many threads … the program will automatically reach the system limit http://stackoverflow.com/questions/18078859/java-run-out-of-memory-issue

（1）尝试优化jvm中垃圾回收器效果，qps提升不明显，且响应时间变化不等 （2）回归程序优化，调整搜索结构， minor gc ：9-10 秒变 15-20秒一次 full gc 3 变为 5-6小时 在响应时间200ms左右条件下，qps从单机平均8-9 提升到15左右 还有优化空间，在保证响应时间下提高吞吐量 传说中的大方法性能更差 https://www.infoq.com/articles/Tuning-Java-Servers