JVM | recolección de basura

JVM | recolección de basura

Java concepto de recolección de basura

• Cómo decidir qué es objetos de basura, el recuento de referencias, el algoritmo de búsqueda de la raíz
• Lo que es Roots GC
  1. Referencia pila JVM
  2. Métodos referencias a variables estáticas distrito
  3. Consulte la JNI (es decir, el método nativo) de
• El área de método (nombre permanente) GC se produce derecha, que los objetos se recuperará?
  1. El método de la zona de recogida de basura para recuperar principalmente de dos partes: constantes de desecho y clase inútil
  2. Serán reciclados en el marco del conjunto de constantes ningún objeto se hace referencia en la GC en otro lugar, es necesario: Constante de residuos
  3. inútiles categorías: clase inútil debe cumplir tres condiciones
     • Todos los objetos instancia se recuperan, la JVM clase no existe ninguna instancia
     • clase de carga de cargador de clases se ha recuperado
     • Clase de objeto de clase no tiene ninguna referencia, no hay lugar para referirse a la clase por la reflexión
  4. máquina virtual puede ser recuperado a base inútil satisface las condiciones anteriores, por -Xnoclassgcel cierre de la recuperación de la clase (expansión leer: la JVM Parámetro Descripción )
  5. En un uso intensivo de la reflexión, proxies dinámicos, escena cargador de clases de costumbre, habrá un gran número de clases se crean, es necesario tener JVM desinstalación clase de entidad.
• Cuando menor GC y GC completa ocurre
  • minorGC oportunidad:
    1. Cuando la JVM no es crear un nuevo espacio de asignación de objetos, dará lugar a GC de menor importancia, tales como el objeto recién creado es mayor que el espacio restante Eden District
    2. Será llamado una vez antes de la plena GC GC menor
    3. Si establece los -XX:+CMSScavengeBeforeRemarkparámetros, CMS llevará a cabo un GC de menor importancia antes de la re-marca
  • oportunidad FullGC:
    1. GC menor cada vez que el objeto fue promovido de la nueva generación en la vejez de la dimensión media de> el espacio restante de la vejez
    2. Después de supervivencia menor de GC de la nueva generación del tamaño total del objeto> el espacio restante de la vejez
    3. Objetos de gran tamaño directamente en la vieja era, entonces el tamaño del objeto es superior a los restantes años de edad espaciales
       • Por -XX:PretenureSizeThreshold=xxxpuede establecer el objeto de gran tamaño estándar, más de este valor, se pone directamente a la vieja tiempo, prestar atención esta vez no es un disparador menor GC
       • parámetros PretenureSizeThreshold solamente para los de serie y ParNew dos colector efectiva, colector paralelo Scavenge no conoce este parámetro, colector Scavenge paralelo generalmente no necesita conjunto. Si se encuentra con una situación que debe utilizar este parámetro, considere una combinación de colector ParNew más el CMS
    4. banda Permanente ( PermGen JDK7 ) o meta-espacio ( la Metadatos jdk8 ) serán insuficientes para desencadenar GC completa
       • Y con espacios de elementos permanentes son hotspot aplicación de la zona método.
       • Meta JDK8 espacio máximo predeterminado a 21M, se puede -XX:MetaspaceSize=xxMestablecer el tamaño del elemento de espacio
       • Ver JVM valores por defecto de parámetros de inicialización:java -XX:+PrintFlagsInitial

basurero

1583730329726.drawio.html 212.12 KB

basurero

La seguridad y la seguridad de la región de punto

我对于安全点的理解,把GC的过程看成街道消毒的过程,用户线程就是在街上跑步前进的人,安全点就是街道上每隔一段距离设置的一个防空洞,街上的人会有三种状态:跑步(running),在防空洞等待消毒完成(block),在街外面等人(in native),每个人状态修改时,必须将自己的状态写在一个本子上(serialization page内存).消毒的时候,必须确保所有人都已经躲进地下的防空洞中了或者在街外等人.这要怎么做呢,首先我准备消毒的时候,会设置一个信号灯(sync_state),在街上跑步的人每路过一个防空洞,都要看一下这个预备消毒的信号灯有没有亮,如果亮了,就躲进防空洞里面,停止跑步,并修改自己的状态为阻塞(block),等消毒完成后在出来继续跑.在消毒的过程中,街道办事处就不允许人修改自己的状态了(设置serialization page只读).
安全区域就是一开始我在防空洞里面睡觉(线程调用sleep),或者我到街外面等人去了(等待IO),在睡觉或者等待的时候,我会把我的状态修改好(block或者in native),而且在我睡醒或者等到人了之后,在回到街道之前,我要去修改我的状态,如果当前街道还在消毒,办事处不会让我改状态的(serialization page只读),只有等到消毒完成,我才可以重新回到街道.

• 安全点的位置

  1. 方法返回前
  2. 调用方法之后
  3. 抛出异常的位置
  4. 循环的末尾
     • 如果for循环中有明确的循环计数器变量，而且该变量有明确的起始值、终止值、步进长度的循环,它有可能被优化为循环末尾没有safepoint，这种循环被称为'counted loop'于是如果这个循环的循环次数很多、循环体里又不调用别的方法或者是调用了方法但被内联进来了，就有可能会导致进入safepoint非常耗时。
     • 解决办法: 把单层循环拆成等价的双重嵌套循环，这样其中一层循环末尾的safepoint就可能会留下来，减少进入safepoint的等待时间。

• 为啥要在这四个地方设置安全点
  JVM要等所有应用线程进入到安全点后才会分派GC任务,如果有线程一直没有进入到安全点,就会导致GC的停顿时间延长.

• 安全点应用实战

  • 生产环境推荐使用-XX:+PrintGCApplicationStoppedTime打印JVM停顿时间,如果GC日志前面有较大的停顿,要就要考虑是不是代码里有较大的循环操作.
  • 在测试环境开启安全点统计日志

    -XX:+UnlockDiagnosticVMOptions
    -XX:+LogVMOutput
    -XX:LogFile=/dev/shm/vm.log
    -XX:+PrintSafepointStatistics
    -XX:PrintSafepointStatisticsCount=1

• 看看大神是怎么解决问题的 无法进入安全点导致GC停顿时间过长问题

• 推荐 JVM安全点介绍及实战

• 推荐 安全点图解

• 推荐 CMS垃圾收集器详细介绍

ID^[1]

---

1. 12466925 ↩