JVM

相关参数设置

-Xms

• 初始分配的大小，默认为物理内存的1/64，可以指定跟Xmx相同大，避免重新分配内存消耗时间

-Xmx

• 最大分配内存，默认为物理内存的1/4

-Xmn

• 尹甸区+幸存区

-Xss

• 线程栈的大小，这个值分配的越大，当前程序可同时创建的线程数越小

Xmx-Xmn就是老年代的大小

获取内存的默认大小

• Runtime.getRuntime().totalMemory()
  Runtime.getRuntime().maxMemory()

XX参数

• -XX:+或者-某个属性值

  • +表示开启，-表示关闭

• -XX:属性值key=属性值value

JVM的堆内存示意图

image.png

所有的创建对象都在尹甸区完成

在幸存0区和幸存1区经过15次垃圾回收会进入养老区，养老区内存满后会进行FullGC

若养老区执行FullGC之后依然无法对对象进行存储，则抛出OOM Error错误

1、永久区（1.7/需要分配） 元数据区（1.8/不需要分配，直接内存）

2、存储项目运行所必须依赖的环境，如Jdk自身所携带的元数据，引入的第三方jar包
3、不会被垃圾回收机制回收掉，直到服务停止才会结束

造成堆内存不足的原因

java虚拟机内存设置不够

• 可以通过指定-Xms，-Xmx参数来指定

代码中创建的大量对象，并且长期不能被垃圾回收器处理（存在引用）

堆内存/栈内存，出现的问题案例

堆内存不足经典案例（OutofMemerryError）

• 1、分页查询，如果没有加分页参数，一次性查询1000万条数据
  2、频繁操作String，没用StringBuilder/StringBuffer
  3、读写的stream流，只管开辟，不管回收

栈内存不足经典案例（StackOverFlowError）

• 无限递归

解决方案

调内存

调垃圾回收机制

• 算法

  • 标记清除算法

    • 标记无用对象，进行清除回收
    • 碎片化

  • 复制算法

    • 按照容量大小分成两个大小相等的内存区域，当一块用完的时候将活着的对象复制到另一块内存上，然后再把已用的内存空间一次清理掉
    • 浪费空间

  • 标记整理算法

    • 标记无用对象，让所有存活的对象向一端移动，清除掉边界以外的内存

  • 增量算法

  • 分代收集算法

    • 根据对象的存活周期将内存分成几块，一般新生代采用复制算法，老年代采用标记整理算法

  • 老年代一般用标记清除、标记整理，年轻代一般采用复制

• 4类7种

  • 方式

    • 串行GC

      • 只有一个线程，执行垃圾回收程序停止的时间长

    • 并行GC

      • 多个线程执行垃圾回收，适用于吞吐量系统

    • 并发GC

      • 系统和垃圾回收一起执行，系统不会停止

    • G1垃圾收集器

  • 7种

    • 新生代GC之Serial收集器
    • 新生代GC之ParNew收集器
    • 新生代GC之Parallel收集器
    • 老年代ParallelOld收集器
    • 老年代SerialOld收集器
    • 老年代CMS收集器

• 判断对象是否可以被垃圾回收

  • 引用计数器法：为每一个对象创建一个引用计数，有对象引用时计算器+1，引用被释放时计数-1，当计数器为0
    时可以被回收，缺点：不能解决循环引用的问题。
  • 可达性分析算法：从GC Roots开始向下搜索，搜索所走过的路径成为引用链。当一个对象到GC roots没有任何引用链相连时，则证明此对象时可以被回收的。

示例

问题描述

• 在某次版本迭代过程中，我们自测通过，联调OK，测试同学在进行全面压测的时候，突然程序假死或者响应卡顿，日志不在打印，过了一会，java服务宕机，问题能够复现

解决

• 其他同学

  • 分析堆内存的文件报告，带上 -XX:+HeapDumpOnOutOfMemoryError: 指定文件输出路径及文件名称参数，如果出现相应的内存溢出，则会在目录下生产一个dump文件，将这个文件使用Memory Analyse Tool工具打开就可以看到当前dump 内存空间的分析内容

• me

  • 1、首先，我dk给我们提供的工具 jstat -gc 进程号 1000(每隔多少毫秒打印一次)
    jstat -gcutil 10777(进程号) 1000
    2、查看伊甸园以及老年代的内存使用情况，我发现每次ygc以后，老年代内存使用率就会提升，然后我对这个java 进程进行持续关注，执行全面压测脚本，发现在经过短暂的时间之后，老年代内存使用情况占比达到90%以上，然后疯狂FullGC，非常频繁。一秒钟2-5次。非常可怕。然后一段时间之后，程序假死，日志不再打印，持续几秒，进程自动终止。服务宕机。
    3、我直接给这个服务 分配 2G的最大内存，给新生代600m，1.4G全留给老年代。
    然后我怀疑是内存给小了，然后我直接跳转参数 -Xmx=2G,重启服务倒要看看，你tm这个老年代你到底能用多少，然后持续全面压测
    1)、如果给多少用多少，那么肯定是代码有问题，再去分析内存dump文件定位代码问题不迟；
    2)、如果最终老年代内存使用，定格在某个值发送不动了，那么证明确实是我给内存分配小了；然后根据它的内存最终占有情况，给他分配一个合理的值，即ok，解决问题！老年代 稳定在1.2G 不再继续增长，FGC频率不再飙升，程序压测无问题，上线。问题完美收官。然后告诉其它小伙伴，你们别瞎鸡儿折腾了！

jdk分析工具

linux

• jstat -gc 进程号 间隔毫秒数

• jstat -gcutil 进程号 间隔毫秒数

• jmap -histo:live 进程号 直接在页面打印内存中对象的情况

• jmap -dump:format=b,file=fileName.hprof 进程号(生成dump文件)

windows

• jconsole 可视化工具 分析 java进程 内存使用情况，线程开辟情况，gc情况....
• jvisualVM★★★★★★，图形界面的，多功能的检测工具，检测大对象。
• jmap -heap 进程号

类加载

类加载过程

image.png

• 加载：.class文件加载到内存
• 验证：保证class文件的正确性
• 准备：为类的静态变量分配内存，赋默认初始值
• 解析：将类的符号引用转换成直接引用
• 初始化：为类的静态成员变量赋正确的值

类加载器的种类

• 1、Bootstrp,用c语言写的
• 2、ExtClassLoader，父加载器是Bootstrp
• 3、AppClassLoader,父加载器是ExtClassLoader

双亲委托机制的工作流程

• 1、当AppClassLoader收到一个类加载的请求时，它不会加载该类，而是委派给父类ExtClassLoader
  2、当ExtClassLoader收到一个类加载的请求时，它也不会加载该类，而是委派给父类Bootstrp
  3、Bootstrp加载失败，就让ExtClassLoader去加载
  4、ExtClassLoader加载失败，就让AppClassLoader去加载
  5、AppClassLoader加载失败，就让自定义类加载器加载（自定义类加载器--继承java.lang.ClassLoader类，重写写findClass(name)方法）
  6、自定义类加载器加载失败，抛出异常
• 好处：避免类的重新加载

JVM的内存结构

本地方法栈

• 被native修饰

  • 融合不同语言编写的接口为java所用

• 调用操作系统相关的资源

栈

程序计数器

• 每一个线程都有一个程序技术器，就是一个指针，指向方法区中的字节码（下一个要执行的指令代码），由执行引擎执行，非常小的内存空间

堆

• 堆内存开辟出来的地址值都是16进制的，以0x开头
• 堆内存的数据都有默认的初始值

方法区

• 被所有线程锁共享，定义的方法信息都保存在该区域，也就是元空间

  • 静态变量、常量、类信息
  • 方法区中的静态变量会有默认的初始值，非静态变量没有

• 字节码文件加载时所进入的内存

• 分为静态区和非静态区

• 静态的成员变量会有默认的初始值，非静态的成员变量没有默认的初始值（要加载进堆内存中才有默认的初始值）

GC种类

普通GC（Minor GC）新生代

全局GC（Major GC）老年代

JVM在垃圾回收，大部分指新生代

引用类别

软引用

• 软引用维护一些可有可无的对象，在内存空间足够的情况下，软引用对象不会被回收

弱引用

• 弱引用相比于软引用，更加没用，拥有更短的生命周期，无论内存是否充足，都会被回收

强引用

• 就算抛出OOM异常，也不会对该对象回收

  • 造成OOM的主要原因之一

虚引用

• 形同虚设

  • 任何时候都可能会被回收

内存溢出与内存泄露

内存溢出

• 申请内存的时候没有给到足够的空间，产生内存溢出

  • 堆内存溢出，栈内存溢出

内存泄露

• 分配出去的内存不再使用，但是无法被回收

  • 长生命周期的对象持有短周期对象的引用，因为长生命周期持有他的引用而不能被回收