Java虚拟机

在Java的编译体系中，一个Java的源代码文件变成计算机可执行的机器指令的过程中，需要经过两段编译： 第一段是把.java文件转换成.class文件。 第二段编译是把.class转换成机器指令的过程

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载7个阶段。其中验证、准备、解析3个部分统称为连接。

总体来讲，对于G1我有几个疑惑，希望能够在这篇文章中得到解决。 G1出现的初衷是什么？ G1适合在什么场景下使用？ G1的trade-off是什么？ G1的详细过程？ 如何理解G1的gc日志? G1的

在某次测试的过程中，发现后端 user服务突然就挂了，用户量并不大，几个人用着用着就不行了。中间层发现大量超时报错，后来去查看user服务的GC日志，发现了一个非常奇怪的现象：Full GC次数竟然比

JVM全称是Java Virtual Machine，Java虚拟机，也就是在计算机上再虚拟一个计算机，这和我们使用 VMWare不一样。

对于HotSpot JVM 使用卡标记（Card Marking）技术来解决老年代到新生代的引用问题。使用卡表（Card Table）和写屏障来进行标记并加快对GC Roots的扫描

安全点，即程序执行时并非在所有地方都能停顿下来开始GC，只有在到达安全点时才能暂停。 安全点（Safepoint）的选定既不太少以至于让GC等待时间太长，也不能过于频繁以致于过分增大运行时的负荷。

现在我们就深入了解一下当前Java GC收集器中的最新流行的代表作：G1收集器(Garbage-First Garbage Collector) 前言 G1收集器是一款在server端运行的垃圾收集器

测试环境压测发现cpu飙升，cpu升高通常情况表示代码中有 大量计算逻辑、死循环、内存泄漏引起的频繁GC也可导致。因此，这类问题可以从以上几个方面排查。

线上服务的GC问题，是Java程序非常典型的一类问题，非常考验工程师排查问题的能力。同时，几乎是面试必考题，但是能真正答好此题的人并不多，要么原理没吃透，要么缺乏实战经验。

Concurrent Mark Sweep (CMS) 收集器是hotspot虚拟机中一款低延迟的并发型垃圾收集器。

如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。下图展示了7种作用于不同分代的收集器，如果两个收集器之间存在连线，就说明它们可以搭配使用。

在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。老年代中因为对象存活率高没有额外空间对它进行分配担保，就使用”标记-整理“算法

当需要排查各种内存溢出、内存泄漏问题时，当垃圾收集成为系统达到更**高并发**量的瓶颈时，我们就需要对这些“自动化“的技术实施必要的监控和调节。

对象的内存分配通常是在 Java 堆上分配（随着虚拟机优化技术的诞生，某些场景下也会在栈上分配，后面会详细介绍），对象主要分配在新生代的 Eden 区，如果启动了本地线程缓冲，将按照线程优先在 TLA