Processo de solução de problemas de animação suspensa do aplicativo e localização e processamento de problemas OutOfMemory

Processo de solução de problemas de animação suspensa do aplicativo e localização e processamento de problemas OutOfMemory

Palavras-chave relacionadas: java8, jmap, jstack, jstat, netstat, menos, grep, jvm

Cenas

Revise o processo de solução de problemas de OOM encontrados anteriormente. Os detalhes do negócio não são mostrados por enquanto. A aparência: o aplicativo congela e a solicitação da interface não pode responder. O principal problema é que o volume de negócios aumenta, um negócio principal tem byte[] e a configuração de heap é relativamente pequena. Processando, otimizando o processo byte[] e aumentando o tamanho do heap.

Processo de solução de problemas:
1.jmap gera uso de heap
2.jstat gera informações de GC
3.jstack gera instantâneo da pilha de threads
4.netstat verifica o status da conexão TCP da porta de escuta
5. Verifica se há um erro OutOfMemory no log

jmap

jmap: o mapa de memória java pode obter arquivos DUMP (instantâneos de heap dump, arquivos binários); também pode obter informações relacionadas à memória do processo java especificado, incluindo o uso de cada área do heap java, informações estatísticas de objetos no heap e informações de carregamento de classe

Produz o status de uso de cada área do heap atual.

Produza a configuração JVM do aplicativo PID atual e o uso das gerações mais novas e mais antigas. Podemos entender o uso de memória do aplicativo e otimizar nosso aplicativo Java conforme necessário.

Sintaxe: jmap -heap pid

Attaching to process ID 29296, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.232-b09

using thread-local object allocation.
Parallel GC with 8 thread(s)

Heap Configuration:
   MinHeapFreeRatio         = x
   MaxHeapFreeRatio         = x
   MaxHeapSize              = x
   NewSize                  = x
   MaxNewSize               = x
   OldSize                  = x
   NewRatio                 = x
   SurvivorRatio            = x
   MetaspaceSize            = x
   CompressedClassSpaceSize = x
   MaxMetaspaceSize         = x
   G1HeapRegionSize         = x

Heap Usage:
PS Young Generation
Eden Space:
   capacity = x
   used     = x
   free     = x
   x% used
From Space:
   capacity = x
   used     = x
   free     = x
   x% used
To Space:
   capacity = x
   used     = x
   free     = x
   x% used
PS Old Generation
   capacity = x
   used     = x
   free     = x
   x% used

x interned Strings occupying x bytes.

O significado de cada parâmetro na configuração de heap:

MinHeapFreeRatio：堆可以被允许的最小空闲大小（以百分比表示）。
MaxHeapFreeRatio：堆中可以被允许的最大空闲空间大小（以百分比表示）。
MaxHeapSize：堆的最大尺寸。
NewSize：JVM 在创建新对象时将分配的内存区大小。
MaxNewSize：新生代的最大尺寸。
OldSize：老年代的初始大小。
NewRatio：新生代和老年代之间的比率。
SurvivorRatio：两个幸存者区域与 Eden 区域的大小比率。
MetaspaceSize：Metaspace 的初始大小（即非堆大小），用于存储加载类、方法等元数据。
CompressedClassSpaceSize：压缩类空间的大小。
MaxMetaspaceSize：Metaspace 的最大大小。
G1HeapRegionSize：G1 中的 Region 大小。每个 Region 的大小由 JVM 计算得出。

在 Heap Usage 部分，我们可以看到当前堆的使用情况，包括：

capacity：Java 堆的总容量。
used：Java 堆当前使用的总量。
free：Java 堆当前可用的数量。
42.22304174399364% used：Java 堆的当前使用率。

PS Young Generation: 年轻代
    Eden Space: eden区
    From Space: 幸存区1
    To Space: 幸存区2
PS Old Generation: 老年代

Produza os 10 objetos que sobrevivem e ocupam mais memória, classificados em ordem decrescente

jmap -histo:live 29296 |head -n 10

Use este comando para verificar se algum objeto anormal ocupa muita memória e causa vazamentos de memória.

Arquivo binário de despejo de saída

Sintaxe: jmap -dump:formato=b,arquivo=heap.bin

Produza o arquivo binário de despejo do heap por meio do comando acima e analise a memória do nosso programa java por meio do jconsole do Eclipse

Parâmetros de configuração JVM

-Xmx4048m  最大堆大小

-Xms4048m  初始堆大小

-Xmn2600m  设置年轻代的大小 建议设置为堆的3/8

-XX:+UseParallelGC  使用并行垃圾收集器，在多 CPU 系统上可以提高垃圾收集的效率。

-XX:-UseAdaptiveSizePolicy  并行收集器会自动选择年轻代区分大小和相应的Survivor区比例
 
-XX:SurvivorRatio=x   幸存区大小比率。

-XX:+HeapDumpOnOutOfMemoryError 在 OutOfMemoryError 异常发生时生成堆转储文件（heap dump）。

Os parâmetros de configuração da JVM podem ser divididos nas seguintes categorias:

标准参数（- 开头）：这些参数主要控制 JVM 的基本行为，并且在所有的 JVM 实现中都支持。

非标准参数（-X 开头）：这些参数是实现特定的，不保证所有 JVM 实现都支持，且在未来的版本中可能会有所改变。

高级参数（-XX 开头）：这些参数被称为高级参数，它们提供了对 JVM 内部行为的细粒度调整，并允许用户绕过某些标准限制。这些参数也是实现特定的，并且在不同的 JVM 实现中可能有所不同。

下面是一些常用的 JVM 参数及其说明：

-Xms：初始堆大小，指定 JVM 启动时堆内存的初始大小。默认情况下，Java 虚拟机自适应地调整堆大小。

-Xmx：最大堆大小，指定 JVM 最大堆内存大小。如果堆超出该阈值，则 Java 虚拟机将抛出 OutOfMemoryError 异常。

-XX:PermSize：永久代初始值，默认值为 64 MB。

-XX:MaxPermSize：永久代最大值，默认值为 64 MB。

-XX:NewSize：新生代初始值，指定了启动时新生代的初始大小。

-XX:MaxNewSize：新生代最大值，指定了新生代的最大可用空间。

-XX:SurvivorRatio：幸存区大小比率。

-XX:+UseConcMarkSweepGC：启用 CMS 垃圾收集器，用于收集老年代内存空间的垃圾。

-XX:+UseParNewGC：启用 ParNew 垃圾收集器，用于收集新生代内存空间的垃圾。

-XX:+UseSerialGC：使用串行垃圾收集器，适用于小型应用程序和单 CPU 系统。

-XX:+UseParallelGC：使用并行垃圾收集器，在多 CPU 系统上可以提高垃圾收集的效率。

-XX:+HeapDumpOnOutOfMemoryError：在 OutOfMemoryError 异常发生时生成堆转储文件（heap dump）。

这些参数只是 JVM 参数中的一小部分，有些参数可能因版本、厂商或系统而异，使用前需要仔细查看文档或手册。

ficar de pé

jstat: ferramenta de monitoramento de estatísticas de máquinas virtuais java

jstat -gcausa pid

jstat -gccapacity pid

jstat -gc pid

opções	ilustrar
-aula	Exibir informações sobre o status de carregamento da classe
-compilador	Exibir estatísticas do compilador JIT
-gc	Exibir informações sobre o status da coleta de lixo
-gccapacidade	Usado para visualizar a capacidade de armazenamento da nova geração, geração antiga e geração persistente
-g porque	Com base em -gc, mostre a causa do último GC
-gcutil	Mostrar informações gerais sobre coleta de lixo

YGC: 从应用程序启动到采样的年轻代中GC的次数
FGC: 从应用程序启动到采样是old代GC的次数
FGCT: 从应用程序启动到采样是Old代GC所用的时间(s)
GCT: 从应用程序启动到采样时GC用的总时间(s)
GCC: 当前GC原因(No GC为当前没有执行GC)
LGCC: 最后一次GC原因

jstack

jstack gera um instantâneo de thread do aplicativo Java atual

Instantâneo do thread de saída jstack pid> theadInfo.log

Quando o processo não responde, o instantâneo do thread é forçado a ser gerado e será exibido se há um deadlock jstack -F pid > theadInfo.log.

RUNNABLE: 线程运行中和IO等待
BLOCKED:  线程在等待Monitor锁
TIMED_WAITING: 线程在等待唤醒，设置了超时时间
WAITING: 线程在无限等待唤醒
IN_NATIVE: 反应的是线程正在运行系统“本机”代码而不是java代码

Na saída de log do jstack:
1. Preste atenção se há um impasse
2. Se há um grande número de bloqueios em nosso próprio código e analise um único thread

netstat

netstat -anp |grep ':porta'

Verifique a porta em que nosso serviço escuta, o status da conexão estabelecida e veja se há algum CLOSE_WAIT anormal

O TCP terá os seguintes estados, que correspondem a cada processo de handshake triplo TCP, transmissão de informações e onda quadridirecional TCP: listen, syn_sent, syn_revd, estabelecido, fin_wait_1, close_wait, fin_wait_2, last_ack, time_wait, closed

CLOSE_WAIT: É formado pelo fechamento passivo da conexão e ocupará uma conexão de rede.
1. O cliente chama a função close para iniciar duas ondas. Depois que o servidor aceitá-lo, ele entrará no estado CLOSE_WAIT. Depois que o cliente receber o ACK do servidor, ele entrará no estado FIN_WAIT_2; mas o servidor ainda não iniciou duas ondas e só completou quatro A conexão é realmente desconectada somente após acenar várias vezes, e só então ambas as partes liberarão os recursos de conexão correspondentes.
2. Se o servidor não chamar close após receber duas ondas, o servidor terá um grande número de conexões no estado CLOSE_WAIT, e cada conexão ocupará os recursos do servidor, o que eventualmente levará a cada vez menos recursos disponíveis no servidor.

TIME_WAIT: Quando o cliente fecha ativamente a conexão, após enviar o último ACK, ele entrará no estado TIME_WAIT e permanecerá por dois tempos máximos de sobrevivência de mensagem (2MLS) para entrar no estado CLOSE.

referência

https://blog.csdn.net/sulijin/article/details/124412379
https://www.nowcoder.com/discuss/388301958082293760