Caso 1: escriba un proceso de uso del paquete sshj para vincular de forma remota una máquina virtual para su funcionamiento.
Fenómeno: no hay problemas en el entorno de la máquina virtual, el host real y las pruebas IDE. Después de ser empujado a la tubería y liberado, el programa se vuelve extremadamente lento después de ejecutarse durante un período de tiempo. El entorno de la tubería es docker.
(Todo el proceso de investigación es extremadamente problemático, porque se realiza para Huawei Cloud y no tiene la autoridad para probar el entorno, y es necesario cooperar con los probadores para pensar en ello como lágrimas).
Método de solución de problemas: jps obtiene todos los procesos de Java. Esta herramienta está disponible cuando se instala jdk.
jstack pid | grep -A 20 -B 20 "nombre de su paquete" Puede obtener la información de la pila de todos los subprocesos en el entorno en ejecución, encontrar el subproceso suspendido para encontrar el problema y luego localizar el problema. grep -A es para mostrar cuántas líneas están escritas por algunos componentes. Si hay 20 líneas, es posible que no pueda verlo. Puede ajustarlo de acuerdo con la situación real. -B está arriba.
El motivo del problema: debido al problema de la versión docker o jdk, el uso de node /dev/random para obtener números aleatorios tiene el problema de hacer cola, y finalmente cambió a un método de adquisición de números aleatorios, y no le importó si es un problema de docker o jdk. Se espera que colgar /dev/random en el área de la ventana acoplable también resuelva el problema.
Caso 2: En términos generales, las fugas de memoria no son fáciles de ocurrir después del alojamiento de primavera, pero después de todo, todavía puede haber miles de demandas.Un proyecto hace mucho tiempo a menudo se cuelga después de un período de práctica, y la última vez es colgar línea de la guardia del proceso. (Solo se puede decir que la lista era grande en esos años).
Método de solución de problemas: jmap -histo pid | grep "Tu propio nombre de paquete" (innumerables bofetadas me dicen en un instante, debes estar seguro de que es tu propio problema. De lo contrario, las bofetadas son muy vergonzosas).
Los dos métodos anteriores básicamente pueden resolver todos los problemas en el proceso de desarrollo, pero solo pueden resolver los problemas que surgen y no pueden mejorar la eficiencia operativa del programa cuando el programa está arreglado.
En términos de implementación real de la aplicación, cuanto mayor sea la configuración de memoria, mejor. Ahora jdk dice que no hay desperdicio de memoria dinámica. Si fuerza un determinado método de recolección de basura, tendrá algún impacto en la eficiencia del uso.
Cada programa tiene su umbral de compilación adecuado para jit Su función es permitirle usar menos memoria de almacenamiento dinámico durante el análisis de escape, lo que también reduce la referencia de memoria de pila a direccionamiento de memoria de almacenamiento dinámico.
通过这个参数进行控制 -XX:CompileThreshold 观察堆内存你自己写的实体内存数量，同一业务并发执行那个少一点。
大概就这些方法了，选gc模式什么的个人觉得有点玄学，不过改改不要stop full world 参数可以让你的程序启动快一点，但是某个内存状态下业务跑的不是特别顺（波动很小，存在理论上的，从没有注意过所以也就不具体些，就是小点一下。）