标准参数: -开头,所有的Hotspot都支持
分标准参数: -X开头,特定版本Hotspot支持特定命令
不稳定: -XX开头,下个版本可能会取消
-XX:+PrintCommandLineFlags 打印虚拟机启动时带的命令行参数
-XX:+PrintFlagsFinal 最终参数值
-XX:+PrintFlagsInitial 默认参数值
java -version
java -X
–new getstatic putstatic invokestatic指令，访问final变量除外
–java.lang.reflect对类进行反射调用时
–初始化子类的时候，父类首先初始化
–虚拟机启动时，被执行的主类必须初始化
–动态语言支持java.lang.invoke.MethodHandle解析的结果为REF_getstatic REF_putstatic REF_invokestatic的方法句柄时，该类必须初始化
1. findInCache -> parent.loadClass -> findClass()
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
}
if (c == null) {
long t1 = System.nanoTime();
c = findClass(name);
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}
1. extends ClassLoader
2. overwrite findClass() -> defineClass(byte[] -> Class clazz)
3. 加密(通过自定义类加载器加载自加密的class,防止反编译,防止篡改)
4.parent是如何指定的，打破双亲委派
1. 用super(parent)指定
2. 双亲委派的打破
1. 如何打破：重写loadClass（）
2. 何时打破过？
1. JDK1.2之前，自定义ClassLoader都必须重写loadClass()
2. ThreadContextClassLoader可以实现基础类调用实现类代码，通过thread.setContextClassLoader指定
3. 热启动，热部署
1. osgi tomcat 都有自己的模块指定classloader（可以加载同一类库的不同版本）
检测热点代码：-XX:CompileThreshold = 10000
解释器: bytecode intepreter (-Xint 使用解释模式,启动很快,执行较慢)
JIT: Just In-Time compiler (-Xcomp 使用纯编译模式,执行很快,启动很慢)
混合模式: 使用解释器+热点代码编译 (默认混合模式 -Xmixed)
开始解释执行,启动速度较快,对热点代码实时检测和编译
热点代码检测
多次被调用的方法(方法计数器: 检测方法执行频率)
多次被调用的循环(循环计数器: 检测循环执行频率)
进行编译
sun.boot.class.path (Bootstrap ClassLoader类加载路径)
java.ext.dirs (ExtensionClassLoader类加载路径)
java.class.path (AppClassLoader类加载路径)
private static String bootClassPath = System.getProperty("sun.boot.class.path");
public static ClassLoader getAppClassLoader(final ClassLoader var0) throws IOException {
final String var1 = System.getProperty("java.class.path");
private static File[] getExtDirs() {
String var0 = System.getProperty("java.ext.dirs");
1. Verification
1. 验证文件是否符合JVM规定
2. Preparation
1. 静态成员变量赋默认值
3. Resolution
1. 将类、方法、属性等符号引用解析为直接引用
常量池中的各种符号引用解析为指针、偏移量等内存地址的直接引用
1. 调用类初始化代码 <clinit>，给静态成员变量赋初始值
2. 小总结：1. load - 默认值 - 初始值
2. new - 申请内存 - 默认值 - 初始值
java内存模型: 线程之间的共享变量存储在主内存中,每个线程都有一个私有的本地内存,本地内存存储了该线程共享变量在主内存中的副本.线程对变量的所有操作都在工作内存中进行,而不能直接读写主内存中的数据,也不能访问其他线程的工作内存;它的工作流程就是,当一个线程A把本地内存中更新过的共享变量刷新到主内存中,另一个线程B到主内存中读取线程A已经修改的值
java内存模型的主要目的是定义程序中各种变量的访问规则,java中线程之间的通信就是由Java内存模型来控制的,JMM决定了一个共享变量的写入在什么时候是对另一个是线程可见的
在Java中的共享变量,所有的实例域,静态域和数组元素都存储在堆内存中,堆内存是所有线程共享的一块内存区域;局部变量,方法定义参数和异常处理参数是线程私有,不会被共享
协议很多 intel 用MESI https://www.cnblogs.com/z00377750/p/9180644.html
现代CPU的数据一致性实现 = 缓存锁(MESI ...) + 总线锁
读取缓存以cache line为基本单位，目前64bytes
位于同一缓存行的两个不同数据，被两个不同CPU锁定，产生互相影响的伪共享问题
使用缓存行的对齐能够提高效率
当CPU访问某个共享变量时,首先看CPU Cache中是否有该变量,如果有,则直接从中获取,否则在主存中获取该变量,把该变量所在的内存区域的一个Cache行大小的内存复制到Cache中.由于存放到Cache行的是内存块而不是单个变量,所以可能会把多个变量存放到一个Cache中.当多个线程同时修改缓存行中的多个变量的时候,同时只能有一个线程能够操作缓存行,这就是伪共享
在CPU与主内存之间存在高速缓冲存储器(Cache),一般集成在CPU内部,Cache内部是以行为单位存储,每一行称为一个Cache行,Cache行是Cache与主内存进行交换数据的基本单位,Cache行的大小一般为2的幂次方,一般为64字节
伪共享的解决方法:可以通过字节填充的方式,也可以用@sun.misc.Contended注解来解决
字节填充,也就是在创建一个变量的时候,使用填充字段来填充该变量所在的缓存行,这样就避免了将多个变量存放在了同一个缓存行中了
使用@sun.misc.Contended注解,用来解决伪共享的问题,像Thread类中的变量threadLocalRandom,threadLocalRandomProbe,threadLocalRandomSecondarySeed中就使用了这个注解,但是默认情况下,@Contended注解只用于java核心类,如rt包下面的类,如果用户需要使用这个注解,添加JVM参数-XX:-RestrictContended,填充的宽度默认为128,自定义宽度可以设置-XX:ContendedPaddingWidth参数
CPU为了提高指令执行效率，会在一条指令执行过程中（比如去内存读数据（慢100倍）），去同时执行另一条指令，前提是，两条指令没有依赖关系
写操作也可以进行合并
合并写技术(WC Buffer) 在寄存器和L1之间有一个WC Buffer,只有四个字节长度的大小
sfence: store| 在sfence指令前的写操作当必须在sfence指令后的写操作前完成。
lfence：load | 在lfence指令前的读操作当必须在lfence指令后的读操作前完成。
mfence：modify/mix | 在mfence指令前的读写操作当必须在mfence指令后的读写操作前完成。原子指令，如x86上的”lock …” 指令是一个Full Barrier，执行时会锁住内存子系统来确保执行顺序，甚至跨多个CPU。Software Locks通常使用了内存屏障或原子指令来实现变量可见性和保持程序顺序
LoadLoad屏障：
对于这样的语句Load1; LoadLoad; Load2，
在Load2及后续读取操作要读取的数据被访问前，保证Load1要读取的数据被读取完毕。
StoreStore屏障：
对于这样的语句Store1; StoreStore; Store2，
在Store2及后续写入操作执行前，保证Store1的写入操作对其它处理器可见。
LoadStore屏障：
对于这样的语句Load1; LoadStore; Store2，
在Store2及后续写入操作被刷出前，保证Load1要读取的数据被读取完毕。
StoreLoad屏障：
对于这样的语句Store1; StoreLoad; Load2，
在Load2及后续所有读取操作执行前，保证Store1的写入对所有处理器可见。
1. 字节码层面
ACC_VOLATILE2. JVM层面
volatile内存区的读写 都加屏障StoreStoreBarrier LoadLoadBarrier
volatile 写操作 volatile 读操作
StoreLoadBarrier LoadStoreBarrier3. OS和硬件层面
https://blog.csdn.net/qq_26222859/article/details/52235930
hsdis - HotSpot Dis Assembler
windows lock 指令实现 | MESI实现
1. 字节码层面
ACC_SYNCHRONIZED
monitorenter monitorexit
2. JVM层面
C C++ 调用了操作系统提供的同步机制
3. OS和硬件层面
X86 : lock cmpxchg / xxx
1. class loading
2. class linking (verification,preparation,)
3. class initializing
4. 申请对象内存
5. 成员变量赋默认值
6. 调用构造方法<init>
1. 成员变量顺序赋初始值
2. 执行构造方法语句
观察虚拟机配置
java -XX:+PrintCommandLineFlags -version1. 普通对象
1. 对象头：markword 8
2. ClassPointer指针：-XX:+UseCompressedClassPointers 为4字节 不开启为8字节
3. 实例数据
1. 引用类型：-XX:+UseCompressedOops 为4字节 不开启为8字节
Oops Ordinary Object Pointers
4. Padding对齐，8的倍数2. 数组对象
1. 对象头：markword 8
2. ClassPointer指针同上
3. 数组长度：4字节
4. 数组数据
5. 对齐 8的倍数
至少包括3位的锁信息,一位是否偏向锁,2位的锁标志位,GC的标记(分带年龄)
看对象的状态来真正分配这64位
1. hashcode部分
31位hashcode->system.identityHashCode(...)
按原始内容计算的hashcode,重写过的hashcode方法计算的结果不会放在这里
如果对象没有重写hashcode方法,那么默认是调用os::random产生hashcode,可以调用System.identityHashCode获取
os::random产生hashcode的规则为next_random=(16807seed)mod(2*31-1),因此可以使用31位存储;另外一旦生成了hashcode,JVM会将其记录在markword中
当调用为重写的hashcode方法以及System.identityHashCode的时候
GC年龄默认为15,原因是分带年龄占4位,最多到15
当一个对象计算过identityHashCode之后，不能进入偏向锁状态
1. 句柄池
2. 直接指针(HotSpot默认)
栈上分配
线程私有小对象
无逃逸 (-XX:-DoEscapeAnalysis)
支持标量替换 (-XX:-EliminateAllocations)
线程本地分配TLAB(Thread Local Allocation Buffer) (-XX:-UseTLAB)
占用eden,默认1%
多线程的时候不用竞争eden就可以申请空间,提高效率
小对象
老年代
大对象
1. 基于寄存器的指令集
2. 基于栈的指令集
Hotspot中的Local Variable Table 类似于寄存器
存放指令位置 每个线程一个程序计数器(线程私有)
虚拟机的运行，类似于这样的循环：
while( not end ) {
取PC中的位置，找到对应位置的指令；
执行该指令；
PC ++;
}
1. Frame - 每个方法对应一个栈帧 线程私有
1. Local Variable Table(局部变量表)
2. Operand Stack(操作数栈)
对于long的处理（store and load），多数虚拟机的实现都是原子的
jls 17.7，没必要加volatile
3. Dynamic Linking(动态链接)
https://blog.csdn.net/qq_41813060/article/details/88379473
jvms 2.6.3
4. return address(方法返回地址)
a() -> b()，方法a调用了方法b, b方法的返回值放在什么地方
所有线程共享 ,主要是每一个class的结构,包括运行时常量池
1. Perm Space (<1.8)
字符串常量位于PermSpace
FGC不会清理
大小启动的时候指定，不能变
2. Meta Space (>=1.8)
字符串常量位于堆
会触发FGC清理
不设定的话，最大就是物理内存
JVM可以直接访问的内核空间的内存 (OS 管理的内存)
NIO ， 提高效率，实现zero copy
思考：
如何证明1.7字符串常量位于Perm，而1.8位于Heap？
提示：结合GC， 一直创建字符串常量，观察堆，和Metaspace
store (将操作数栈中的数据弹出赋值给局部变量表)
load(将局部变量表中的数据压入操作数栈)
pop(弹出操作数栈顶元素)
dmp(将操作数栈顶元素复制到栈顶)
mul
sub
invoke
1. InvokeStatic
2. InvokeVirtual
3. InvokeInterface
4. InovkeSpecial
可以直接定位，不需要多态的方法
private 方法 ， 构造方法
5. InvokeDynamic
JVM最难的指令
lambda表达式或者反射或者其他动态语言scala kotlin，或者CGLib ASM，动态产生的class，会用到的指令
没有任何引用指向的一个对象或者多个对象（循环引用）
1. 引用计数（ReferenceCount）
2. 根可达算法(RootSearching) (Hotspot用这种)根包括: 虚拟机栈,本地方法栈,运行时常量池,方法区的静态引用,Class问价
1. 标记清除(mark sweep) - 位置不连续 产生碎片 效率偏低（两遍扫描）
算法相对简单,存活对象比较多的情况下效率较高 用于(老年代cms)
2. 拷贝算法 (copying) - 浪费空间,移动复制对象,需要调整对象的引用
适用于存活对象较少的情况,只扫描一次,效率较高,没有碎片 用于(新生代都用这种)
3. 标记压缩(mark compact) - 扫描两次,需要移动对象,调整指针,效率较低
不会产生碎片,方便对象分配,不会产生内存减半
1. 部分垃圾回收器使用的模型
除Epsilon ZGC Shenandoah之外的GC都是使用逻辑分代模型
G1是逻辑分代，物理不分代
除此之外不仅逻辑分代，而且物理分代
2. 新生代 + 老年代 + 永久代（1.7）Perm Generation/ 元数据区(1.8) Metaspace
1. 永久代 元数据 - Class
2. 永久代必须指定大小限制 ，元数据可以设置，也可以不设置，无上限（受限于物理内存）
3. 字符串常量 1.7 - 永久代，1.8 - 堆
4. MethodArea逻辑概念 - 永久代、元数据3. 老年代满了FGC Full GC
1. 尽量减少FGC
2. MinorGC = YGC
3. MajorGC = FGC
栈上分配
线程私有小对象
无逃逸 (-XX:-DoEscapeAnalysis)
支持标量替换 (-XX:-EliminateAllocations)
线程本地分配TLAB(Thread Local Allocation Buffer) (-XX:-UseTLAB)
占用eden,默认1%
多线程的时候不用竞争eden就可以申请空间,提高效率
小对象
老年代
大对象
1.超过-XX:MaxTenuringThreshold指定次数(YGC)
Parallel Scavenge 15
G1 15
CMS 6
2.动态年龄：（不重要）
存活对象超过s2的50%,把超过50%的对象直接放到老年代3. 分配担保：（不重要）
YGC期间 survivor区空间不够了 空间担保直接进入老年代
1. JDK诞生 Serial追随 提高效率，诞生了PS，为了配合CMS，诞生了PN，CMS是1.4版本后期引入，CMS是里程碑式的GC，它开启了并发回收的过程，但是CMS毛病较多，因此目前任何一个JDK版本默认是CMS
并发垃圾回收是因为无法忍受STW
2. Serial 年轻代 串行回收
3. SerialOld
4. PS 年轻代 并行回收
5. ParNew 年轻代 配合CMS的并行回收
6. ParallelOld
7. ConcurrentMarkSweep 老年代 并发的， 垃圾回收和应用程序同时运行，降低STW的时间(200ms)
CMS问题比较多，所以现在没有一个版本默认是CMS，只能手工指定
CMS既然是MarkSweep，就一定会有碎片化的问题，碎片到达一定程度，CMS的老年代分配对象分配不下的时候，使用SerialOld 进行老年代回收
还有就是浮动垃圾
想象一下：
PS + PO -> 加内存 换垃圾回收器 -> PN + CMS + SerialOld（几个小时 - 几天的STW）
几十个G的内存，单线程回收 -> G1 + FGC 几十个G -> 上T内存的服务器 ZGC
算法：三色标记 + Incremental Update
8. G1(10ms)
算法：三色标记 + SATB
9. ZGC (1ms) PK C++
算法：ColoredPointers + LoadBarrier
10. Shenandoah
算法：ColoredPointers + WriteBarrier
11. Eplison
12. PS 和 PN区别
PS吞吐量优先 PN响应时间优先
13. 垃圾收集器跟内存大小的关系
1. Serial 几十兆
2. PS 上百兆 - 几个G
3. CMS - 20G
4. G1 - 上百G
5. ZGC - 4T - 16T（JDK13）
1.8默认的垃圾回收：PS + ParallelOld
浮动垃圾产生于并发清理阶段,下一次垃圾回收会被回收掉
1.加大JVM内存
2.加大Young的比例
3.提高Y-O的年龄
4.提高S区比例
5.避免代码内存泄漏
是一种服务端使用的垃圾回收器,目标是用在多核,大内存的机器上,大多数情况下可以实现指定的GC停顿时间,同时还能保持较高的吞吐量
并发收集
压缩空闲时间不会延长GC的暂停时间
更容易预测GC的停顿时间
以用于不需要实现很高的吞吐量的场景
5%~60%
一般不用手工指定
也不要手工指定,因为这是G1预测停顿时间的基准
YGC: eden空间不足 多线程并行执行
MixedGC XX:InitiatingHeapOccupacyPercent 默认值45%,当O超过这个值时,启动MixedGC
FGC: old空间不足 System.gc()
1. 扩内存
2. 提高CPU性能（回收的快，业务逻辑产生对象的速度固定，垃圾回收越快，内存空间越大）
3. 降低MixedGC触发的阈值，让MixedGC提早发生（默认是45%）java 10 以前是串行FullGC,之后是并行FullGC
初始标记 STW
并发标记
最终标记 STW (重新标记)
筛选回收 STW (并行)
一组可被回收的分区的集合.
在CSet中存活的数据会在GC过程中被移动到另一个可用分区,CSet中的分区可以来自Eden空间,survivor空间,或者老年代.
CSet会占用不到整个堆空间的1%大小
主要用来解决跨代引用的问题
记忆集是一种用于记录从非收集区域指向收集区域的指针集合的抽象数据结构
记录了其他Region中的对象到本Region的引用,key是别的region的起始地址,value是本region中卡表的索引号
RSet的价值在于,使得垃圾收集器不需要扫描整个堆找到谁引用了当前分区中的对象,只需要扫描RSet即可
记忆集占用10%~20%的空间
马士兵
由于做YGC时，需要扫描整个OLD区，效率非常低，所以JVM设计了CardTable， 如果一个OLD区CardTable中有对象指向Y区，就将它设为Dirty，下次扫描时，只需要扫描Dirty Card
在结构上，Card Table用BitMap来实现深入理解java虚拟机
主要用来解决跨代引用的问题,结构上用的字节数组
字节数组Card_Table的每一个元素都对应着其标识的内存区域中一块特定大小的内存块,这个内存块被称为"卡页", Hotspot卡页大小为2的9次幂
三色标记法
白色: 未被标记的对象
灰色: 自身被标记,成员变量未被标记
黑色: 自身和成员变量均已标记完成
漏标的两个充要条件
在remark过程中,黑色指向了白色
灰色指向白色的引用没了
打破漏标的两个条件之一即可
1. incremental update 增量更新,关注引用的增加,(CMS用这种)
把黑色对象重新标记为灰色,下次重新扫描属性
2. STAP snapshot at the beginning -关注引用的删除 (G1用这种)
当B->D消失时,要把这个引用推到GC的堆栈,保证D还能被GC扫描到
1. 吞吐量：用户代码时间 /（用户代码执行时间 + 垃圾回收时间）
2. 响应时间：STW越短，响应时间越好所谓调优，首先确定，追求啥？吞吐量优先，还是响应时间优先？还是在满足一定的响应时间的情况下，要求达到多大的吞吐量...
问题：
科学计算，吞吐量。数据挖掘，thrput。吞吐量优先的一般：（PS + PO）
响应时间：网站 GUI API （1.8 G1）
1. 根据需求进行JVM规划和预调优
2. 优化运行JVM运行环境（慢，卡顿）
3. 解决JVM运行过程中出现的各种问题(OOM)
调优，从业务场景开始，没有业务场景的调优都是耍流氓
无监控（压力测试，能看到结果），不调优步骤：
1. 熟悉业务场景（没有最好的垃圾回收器，只有最合适的垃圾回收器）
1. 响应时间、停顿时间 [CMS G1 ZGC] （需要给用户作响应）
2. 吞吐量 = 用户时间 /( 用户时间 + GC时间) [PS]
2. 选择回收器组合
3. 计算内存需求（经验值 1.5G 16G）
4. 选定CPU（越高越好）
5. 设定年代大小、升级年龄
6. 设定日志参数
1. -Xloggc:/opt/xxx/logs/xxx-xxx-gc-%t.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=20M -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCCause
2. 或者每天产生一个日志文件
7. 观察日志情况
JVM的命令行参数参考：https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
HotSpot参数分类
标准： - 开头，所有的HotSpot都支持
非标准：-X 开头，特定版本HotSpot支持特定命令
不稳定：-XX 开头，下个版本可能取消java -version
java -X
1. 区分概念：内存泄漏memory leak，内存溢出out of memory
2. java -XX:+PrintCommandLineFlags HelloGC
3. java -Xmn10M -Xms40M -Xmx60M -XX:+PrintCommandLineFlags -XX:+PrintGC HelloGC
PrintGCDetails PrintGCTimeStamps PrintGCCauses
4. java -XX:+UseConcMarkSweepGC -XX:+PrintCommandLineFlags HelloGC
5. java -XX:+PrintFlagsInitial 默认参数值
6. java -XX:+PrintFlagsFinal 最终参数值
7. java -XX:+PrintFlagsFinal | grep xxx 找到对应的参数
8. java -XX:+PrintFlagsFinal -version |grep GC
小堆影响不大，大堆会有服务暂停或卡顿（加live可以缓解），dump前会有FGC
栈 堆 MethodArea 直接内存
有一个50万PV的资料类网站（从磁盘提取文档到内存）原服务器32位，1.5G
的堆，用户反馈网站比较缓慢，因此公司决定升级，新的服务器为64位，16G
的堆内存，结果用户反馈卡顿十分严重，反而比以前效率更低了
1. 为什么原网站慢?
很多用户浏览数据，很多数据load到内存，内存不足，频繁GC，STW长，响应时间变慢
2. 为什么会更卡顿？
内存越大，FGC时间越长
3. 咋办？
PS -> PN + CMS 或者 G1
CPU100%那么一定有线程在占用系统资源，
1. 找出哪个进程cpu高（top）
2. 该进程中的哪个线程cpu高（top -Hp）
3. 导出该线程的堆栈 (jstack)
4. 查找哪个方法（栈帧）消耗时间 (jstack)
5. 工作线程占比高 | 垃圾回收线程占比高
1. 导出堆内存 (jmap)
2. 分析 (jhat jvisualvm mat jprofiler ... )
1. jstat jvisualvm jprofiler arthas top...
案例1：垂直电商，最高每日百万订单，处理订单系统需要什么样的服务器配置？
这个问题比较业余，因为很多不同的服务器配置都能支撑(1.5G 16G)
1小时360000集中时间段， 100个订单/秒，（找一小时内的高峰期，1000订单/秒）
经验值，
非要计算：一个订单产生需要多少内存？512K * 1000 500M内存
专业一点儿问法：要求响应时间100ms
压测！案例2：12306遭遇春节大规模抢票应该如何支撑？
12306应该是中国并发量最大的秒杀网站：
号称并发量100W最高
CDN -> LVS -> NGINX -> 业务系统 -> 每台机器1W并发（10K问题） 100台机器
普通电商订单 -> 下单 ->订单系统（IO）减库存 ->等待用户付款
12306的一种可能的模型： 下单 -> 减库存 和 订单(redis kafka) 同时异步进行 ->等付款
减库存最后还会把压力压到一台服务器
可以做分布式本地库存 + 单独服务器做库存均衡
大流量的处理方法：分而治之* 怎么得到一个事务会消耗多少内存？
1. 弄台机器，看能承受多少TPS？是不是达到目标？扩容或调优，让它达到
2. 用压测来确定
1.测试代码
import java.math.BigDecimal;
import java.util.*;
import java.util.concurrent.ScheduledThreadPoolExecutor;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
/**
* 从数据库中读取信用数据，套用模型，并把结果进行记录和传输
*/
public class TestFullGC {
private static class CardInfo {
BigDecimal price = new BigDecimal(0.0);
String name = "张三";
int age = 5;
Date birthdate = new Date();
public void m() {
}
}
private static ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor(50,
new ThreadPoolExecutor.DiscardOldestPolicy());
public static void main(String[] args) throws Exception {
executor.setMaximumPoolSize(50);
for (; ; ) {
modelFit();
Thread.sleep(100);
}
}
private static void modelFit() {
List<CardInfo> taskList = getAllCardInfo();
taskList.forEach(info -> {
// do something
executor.scheduleWithFixedDelay(() -> {
//do sth with info
info.m();
}, 2, 3, TimeUnit.SECONDS);
});
}
private static List<CardInfo> getAllCardInfo() {
List<CardInfo> taskList = new ArrayList<>();
for (int i = 0; i < 100; i++) {
CardInfo ci = new CardInfo();
taskList.add(ci);
}
return taskList;
}
}
2. java -Xms200M -Xmx200M -XX:+PrintGC com.mashibing.jvm.gc.T15_FullGC_Problem01
3. 一般是运维团队首先受到报警信息（CPU Memory）
4. top命令观察到问题：内存不断增长 CPU占用率居高不下
5. top -Hp 观察进程中的线程，哪个线程CPU和内存占比高
6. jps定位具体java进程
jstack 定位线程状况，重点关注：WAITING BLOCKED
eg.查死锁
waiting on <0x0000000088ca3310> (a java.lang.Object)
假如有一个进程中100个线程，很多线程都在waiting on <xx> ，一定要找到是哪个线程持有这把锁
怎么找？搜索jstack dump的信息，找<xx> ，看哪个线程持有这把锁RUNNABLE
7. 为什么阿里规范里规定，线程的名称（尤其是线程池）都要写有意义的名称
怎么样自定义线程池里的线程名称？（自定义ThreadFactory）
8. jinfo pid 打印进程状态
9. jstat -gc 动态观察gc情况 / 阅读GC日志发现频繁GC / arthas观察 / jconsole/jvisualVM/ Jprofiler（最好用）
jstat -gc 4655 500 : 每个500个毫秒打印GC的情况
怎么定位OOM问题的？不能用图形界面,影响性能
1：已经上线的系统不用图形界面用什么？（cmdline arthas）
2：图形界面到底用在什么地方？测试！测试的时候进行监控！（压测观察）
10. jmap - histo 4655 | head -20，查找有多少对象产生
11. jmap -dump:format=b,file=xxx pid ：
线上系统，内存特别大，jmap执行期间会对进程产生很大影响，甚至卡顿（电商不适合）
1：设定了参数HeapDump，OOM的时候会自动产生堆转储文件
2：很多服务器备份（高可用），停掉这台服务器对其他服务器不影响
3：在线定位(一般小点儿公司用不到)
12. java -Xms20M -Xmx20M -XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError com.mashibing.jvm.gc.T15_FullGC_Problem01
13. 使用MAT / jhat /jvisualvm 进行dump文件分析
https://www.cnblogs.com/baihuitestsoftware/articles/6406271.html
jhat -J-mx512M xxx.dump
http://192.168.17.11:7000
拉到最后：找到对应链接
可以使用OQL查找特定问题对象
14. 找到代码的问题
为什么需要在线排查？
在生产上我们经常会碰到一些不好排查的问题，例如线程安全问题，用最简单的threaddump或者heapdump不好查到问题原因。为了排查这些问题，有时我们会临时加一些日志，比如在一些关键的函数里打印出入参，然后重新打包发布，如果打了日志还是没找到问题，继续加日志，重新打包发布。对于上线流程复杂而且审核比较严的公司，从改代码到上线需要层层的流转，会大大影响问题排查的进度。
使用方式:进入arthas目录,使用命令 java -jar arthas-boot.jar 启动arthas,会找到对应进程,输入进程号,会把arthas挂在对应进程上面,然后可以通过命令查看进程状态
jvm 观察jvm详细配置信息
thread 列出当前进程有多少个线程 定位线程问题
Thread + 线程号 列出具体线程的信息
dashboard 观察系统情况,类似于top命令heapdump 到处堆转储文件,类似于jmap的转储功能
heapdump + jhat分析jhat -J-mx512M xxx.dump
http://192.168.17.11:7000
拉到最后：找到对应链接
可以使用OQL查找特定问题对象
jad反编译
动态代理生成类的问题定位
第三方的类（观察代码）
版本问题（确定自己最新提交的版本是不是被使用）
redefine 热替换
目前有些限制条件：只能改方法实现（方法已经运行完成），不能改方法名， 不能改属性
m() -> mm()
sc - search class
watch - watch method
没有包含的功能：jmap
1. 硬件升级系统反而卡顿的问题（见上）
2. 线程池不当运用产生OOM问题（见上）
不断的往List里加对象（实在太LOW）4. tomcat http-header-size过大问题（Hector）
5. lambda表达式导致方法区溢出问题(MethodArea / Perm Metaspace)
LambdaGC.java -XX:MaxMetaspaceSize=9M -XX:+PrintGCDetails6. 直接内存溢出问题（少见）
《深入理解Java虚拟机》P59，使用Unsafe分配直接内存，或者使用NIO的问题7. 栈溢出问题
-Xss设定太小
8. 比较一下这两段程序的异同，分析哪一个是更优的写法：
9. 重写finalize引发频繁GC
小米云，HBase同步系统，系统通过nginx访问超时报警，最后排查，C++程序员重写finalize引发频繁GC问题
为什么C++程序员会重写finalize？（new delete）
finalize耗时比较长（200ms）
10. 如果有一个系统，内存一直消耗不超过10%，但是观察GC日志，发现FGC总是频繁产生，会是什么引起的？
System.gc() (这个比较Low)11. Distuptor有个可以设置链的长度，如果过大，然后对象大，消费完不主动释放，会溢出
12. 用jvm都会溢出，mycat用崩过，1.6.5某个临时版本解析sql子查询算法有问题，9个exists的联合sql就导致生成几百万的对象
13. new 大量线程，会产生 native thread OOM，（low）应该用线程池，
解决方案：减少堆空间（太TMlow了）,预留更多内存产生native thread
JVM内存占物理内存比例 50% - 80%
每种垃圾回收器的日志格式是不同的！
PS日志格式
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0Q5iXJUl-1621865321029)(./GC日志详解.png)]
heap dump部分：
```java
eden space 5632K, 94% used [0x00000000ff980000,0x00000000ffeb3e28,0x00000000fff00000)
后面的内存地址指的是，起始地址，使用空间结束地址，整体空间结束地址
```[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZWXltCKE-1621865321031)(GCHeapDump.png)]
total = eden + 1个survivor
1. Memory Fragmentation(内存碎片)
-XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction 默认为0 指的是经过多少次FGC才进行压缩2. Floating Garbage(浮动垃圾)
Concurrent Mode Failure
产生：if the concurrent collector is unable to finish reclaiming the unreachable objects before the tenured generation fills up, or if an allocation cannot be satisfiedwith the available free space blocks in the tenured generation, then theapplication is paused and the collection is completed with all the applicationthreads stopped
解决方案：降低触发CMS的阈值
PromotionFailed
解决方案类似，保持老年代有足够的空间
–XX:CMSInitiatingOccupancyFraction 92% 可以降低这个值，让CMS保持老年代足够的空间
执行命令：java -Xms20M -Xmx20M -XX:+PrintGCDetails -XX:+UseConcMarkSweepGC com.study.jvm.gc.T15_FullGC_Problem01
[GC (Allocation Failure) [ParNew: 6144K->640K(6144K), 0.0265885 secs] 6585K->2770K(19840K), 0.0268035 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
// ParNew：年轻代收集器
// 6144->640：收集前后的对比
//（6144）：整个年轻代容量
// 6585 -> 2770：整个堆的情况
//（19840）：整个堆大小
[GC (CMS Initial Mark) [1 CMS-initial-mark: 8511K(13696K)] 9866K(19840K), 0.0040321 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
//8511 (13696) : 老年代使用（最大）
//9866 (19840) : 整个堆使用（最大）
[CMS-concurrent-mark-start]
[CMS-concurrent-mark: 0.018/0.018 secs] [Times: user=0.01 sys=0.00, real=0.02 secs]
//这里的时间意义不大，因为是并发执行
[CMS-concurrent-preclean-start]
[CMS-concurrent-preclean: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
//标记Card为Dirty，也称为Card Marking
[GC (CMS Final Remark) [YG occupancy: 1597 K (6144 K)][Rescan (parallel) , 0.0008396 secs][weak refs processing, 0.0000138 secs][class unloading, 0.0005404 secs][scrub symbol table, 0.0006169 secs][scrub string table, 0.0004903 secs][1 CMS-remark: 8511K(13696K)] 10108K(19840K), 0.0039567 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
//STW阶段，YG occupancy:年轻代占用及容量
//[Rescan (parallel)：STW下的存活对象标记
//weak refs processing: 弱引用处理
//class unloading: 卸载用不到的class
//scrub symbol(string) table:
//cleaning up symbol and string tables which hold class-level metadata and
//internalized string respectively
//CMS-remark: 8511K(13696K): 阶段过后的老年代占用及容量
//10108K(19840K): 阶段过后的堆占用及容量[CMS-concurrent-sweep-start]
[CMS-concurrent-sweep: 0.005/0.005 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
//标记已经完成，进行并发清理
[CMS-concurrent-reset-start]
[CMS-concurrent-reset: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
//重置内部结构，为下次GC做准备
[GC pause (G1 Evacuation Pause) (young) (initial-mark), 0.0015790 secs]
//young -> 年轻代 Evacuation-> 复制存活对象
//initial-mark 混合回收的阶段，这里是YGC混合老年代回收
[Parallel Time: 1.5 ms, GC Workers: 1] //一个GC线程
[GC Worker Start (ms): 92635.7]
[Ext Root Scanning (ms): 1.1]
[Update RS (ms): 0.0]
[Processed Buffers: 1]
[Scan RS (ms): 0.0]
[Code Root Scanning (ms): 0.0]
[Object Copy (ms): 0.1]
[Termination (ms): 0.0]
[Termination Attempts: 1]
[GC Worker Other (ms): 0.0]
[GC Worker Total (ms): 1.2]
[GC Worker End (ms): 92636.9]
[Code Root Fixup: 0.0 ms]
[Code Root Purge: 0.0 ms]
[Clear CT: 0.0 ms]
[Other: 0.1 ms]
[Choose CSet: 0.0 ms]
[Ref Proc: 0.0 ms]
[Ref Enq: 0.0 ms]
[Redirty Cards: 0.0 ms]
[Humongous Register: 0.0 ms]
[Humongous Reclaim: 0.0 ms]
[Free CSet: 0.0 ms]
[Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 18.8M(20.0M)->18.8M(20.0M)]
[Times: user=0.00 sys=0.00, real=0.00 secs]
//以下是混合回收其他阶段
[GC concurrent-root-region-scan-start]
[GC concurrent-root-region-scan-end, 0.0000078 secs]
[GC concurrent-mark-start]
//无法evacuation，进行FGC
[Full GC (Allocation Failure) 18M->18M(20M), 0.0719656 secs]
[Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 18.8M(20.0M)->18.8M(20.0M)], [Metaspace: 38
76K->3876K(1056768K)] [Times: user=0.07 sys=0.00, real=0.07 secs]
-XX:+UseSerialGC = Serial New (DefNew) + Serial Old
小型程序。默认情况下不会是这种选项，HotSpot会根据计算及配置和JDK版本自动选择收集器
-XX:+UseParNewGC = ParNew + SerialOld
这个组合已经很少用（在某些版本中已经废弃）
https://stackoverflow.com/questions/34962257/why-remove-support-for-parnewserialold-anddefnewcms-in-the-future
-XX:+UseConcurrentMarkSweepGC = ParNew + CMS + Serial Old
-XX:+UseParallelGC = Parallel Scavenge + Parallel Old (1.8默认) 【PS + SerialOld】
-XX:+UseParallelOldGC = Parallel Scavenge + Parallel Old
-XX:+UseG1GC = G1
Linux中没找到默认GC的查看方法，而windows中会打印UseParallelGC
java +XX:+PrintCommandLineFlags -version
通过GC的日志来分辨Linux下1.8版本默认的垃圾回收器到底是什么？
1.8.0_181 默认（看不出来）Copy MarkCompact
1.8.0_222 默认 PS + PO
-Xmn -Xms -Xmx -Xss
年轻代 最小堆 最大堆 栈空间
-XX:+UseTLAB
使用TLAB，默认打开
-XX:+PrintTLAB
打印TLAB的使用情况
-XX:TLABSize
设置TLAB大小
-XX:+DisableExplictGC
System.gc()不管用 ，FGC
-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintHeapAtGC
-XX:+PrintGCTimeStamps
-XX:+PrintGCApplicationConcurrentTime (低)
打印应用程序时间
-XX:+PrintGCApplicationStoppedTime （低）
打印暂停时长
-XX:+PrintReferenceGC （重要性低）
记录回收了多少种不同引用类型的引用
-verbose:class
类加载详细过程
-XX:+PrintVMOptions
-XX:+PrintFlagsFinal -XX:+PrintFlagsInitial
必须会用
-Xloggc:opt/log/gc.log
-XX:MaxTenuringThreshold
升代年龄，最大值15
锁自旋次数 -XX:PreBlockSpin 热点代码检测参数-XX:CompileThreshold 逃逸分析 标量替换 ...
这些不建议设置
-XX:SurvivorRatio
-XX:PreTenureSizeThreshold
大对象到底多大
-XX:MaxTenuringThreshold
-XX:+ParallelGCThreads
并行收集器的线程数，同样适用于CMS，一般设为和CPU核数相同
-XX:+UseAdaptiveSizePolicy
自动选择各区大小比例
-XX:+UseConcMarkSweepGC
-XX:ParallelCMSThreads
CMS线程数量
-XX:CMSInitiatingOccupancyFraction
使用多少比例的老年代后开始CMS收集，默认是68%(近似值)，如果频繁发生SerialOld卡顿，应该调小，（频繁CMS回收）
-XX:+UseCMSCompactAtFullCollection
在FGC时进行压缩
-XX:CMSFullGCsBeforeCompaction
多少次FGC之后进行压缩
-XX:+CMSClassUnloadingEnabled
-XX:CMSInitiatingPermOccupancyFraction
达到什么比例时进行Perm回收
GCTimeRatio
设置GC时间占用程序运行时间的百分比
-XX:MaxGCPauseMillis
停顿时间，是一个建议时间，GC会尝试用各种手段达到这个时间，比如减小年轻代
-XX:+UseG1GC
-XX:MaxGCPauseMillis
建议值，G1会尝试调整Young区的块数来达到这个值
-XX:GCPauseIntervalMillis
？GC的间隔时间
-XX:+G1HeapRegionSize
分区大小，建议逐渐增大该值，1 2 4 8 16 32。
随着size增加，垃圾的存活时间更长，GC间隔更长，但每次GC的时间也会更长
ZGC做了改进（动态区块大小）
G1NewSizePercent
新生代最小比例，默认为5%
G1MaxNewSizePercent
新生代最大比例，默认为60%
GCTimeRatio
GC时间建议比例，G1会根据这个值调整堆空间
ConcGCThreads
线程数量
InitiatingHeapOccupancyPercent
启动G1的堆空间占用比例
强引用: 指程序代码之中普遍存在的引用赋值,只要强引用关系还存在,垃圾收集器永远不会回收被引用的对象
软引用:用来描述一些还有用但是非必须的对象,被软引用关联着的对象,在系统将要发生内存溢出前,会把这些对象列入回收范围进行二次回收,也就是当空间不够了,才进行回收(SoftReference)
用途:软引用可用于缓存,没有容器
弱引用:弱引用用来描述哪些非必须的对象,只要垃圾回收器开始回收,一定会回收弱引用所指向的对象(WeakReference)
用途:一般用在容器中
虚引用:是一种最弱的引用,一个对象是否有虚引用的存在,完全不会对其生存时间构成影响,也无法通过虚引用来取得一个对象的实例
用途:对象死后的后事操作,用于管理直接内存,会给垃圾回收线程一个通知。虚引用所指向的那个对象被回收的时候,会被扔到一个应用队列中,对检测到队列中的对象有被回收了,对象它是否使用了堆外内存,有就回收堆外内存
当对象被回收时,通过Queue可以检测到,然后清理堆外内存