小丑竟是我自己

系统频繁Full GC导致系统卡顿是怎么回事机器配置：2核4G JVM内存大小：2G 系统运行时间：7天 期间发生的Full GC次数和耗时：500多次，200多秒 期间发生的Young GC次数和耗时：1万多次，500多秒大致算下来每天会发生70多次Full GC，平均每小时3次，每次Full GC在400毫秒左右；每天会发生1000多次Young GC，每分钟会发生1次，每次Young GC在50毫秒左右。JVM参数设置如下：-Xms1536M -Xmx1536M -Xmn5

前置启动程序 事先启动一个web应用程序，用jps查看其进程id，接着用各种jdk自带命令优化应用 Jmap 此命令可以用来查看内存信息，实例个数以及占用内存大小

垃圾收集器G1详解

在新生代做GCRoots可达性扫描过程中可能会碰到跨代引用的对象，这种如果又去对老年代再去扫描效率太低了。 为此，在新生代可以引入记录集（Remember Set）的数据结构（记录从非收集区到收集区的指针集合），避免把整个老年代加入GCRoots扫描范围。事实上并不只是新生代、 老年代之间才有跨代引用的问题， 所有涉及部分区域收集（Partial GC） 行为的垃圾收集器， 典型的如G1、 ZGC和Shenandoah收集器， 都会面临相同的问题。 垃圾收集场景中，收集器只需通过记忆集判断出某一块非

三色标记内容点击下面链接region（区域）SATB相对增量更新效率会高(当然SATB可能造成更多的浮动垃圾)，因为不需要在重新标记阶段再次深度扫描被删除引用对象，而CMS对增量引用的根对象会做深度扫描，G1因为很多对象都位于不同的region，CMS就一块老年代区域，重新深度扫描对象的话G1的代价会比CMS高，所以G1选择SATB不深度扫描对象，只是简单标记，等到下一轮GC再深度扫描。 ...

三色标记在并发标记的过程中，因为标记期间应用线程还在继续跑，对象间的引用可能发生变化，多标和漏标的情况就有可能发生。 这里我们引入“三色标记”来给大家解释下，把Gcroots可达性分析遍历对象过程中遇到的对象， 按照“是否访问过”这个条件标记成以下三种颜色：黑色： 表示对象已经被垃圾收集器访问过， 且这个对象的所有引用都已经扫描过。 黑色的对象代表已经扫描过， 它是安全存活的， 如果有其他对象引用指向了黑色对象， 无须重新扫描一遍。 黑色对象不可能直接（不经过灰色对象） 指向某个白色对象。

拿网上最长说的电商举例吧，因为电商技术覆盖面广，流量大。大型电商系统后端现在一般都是拆分为多个子系统部署的，比如，商品系统，库存系统，订单系统，促销系统，会员系统等等。 我们这里以比较核心的订单系统为例 （各家订单系统不一样，我的公司当初在做订单的时候，是存储了商品快照的，除订单对象外，生成的其他对象比较大。）对于8G内存，我们一般是分配4G内存给JVM，正常的JVM参数配置如下： ‐Xms3072M ‐Xmx3072M ‐Xss1M ‐XX:Metasp.

垃圾收集算法

JVM字节码文件结构深度剖析

先看下流程图

先了解下对象的创建过程

首先了解一下JDK体系结构JRE就是Java运行环境（Java Runtime Environment，简称JRE）简单点说就是支撑java运行的核心类库、核心环境。

Tomcat打破双亲委派机制

java.exe调用底层的jvm.dll文件创建java虚拟机（C++实现）java.exe 底层C或C++实现，通过C++实现的代码调用C、C++语言的库函数jvm.dll，创建java虚拟机。dll文件相当于java的jar包。C++语言的启动程序，整了一个JVM，然后JVM会创建很多java实现的类加载器，通过这些类加载器去真正调用类加载器里面loadClass方法，去加载磁盘上的字节码文件。加载到内存之后，C语言会直接调用main方法。...