El ajuste continuo del negocio antiguo, el desarrollo continuo de nuevos requisitos y la iteración continua de la versión son un status quo inmutable del proyecto actual. Además, el estilo y el nivel del código de cada desarrollador es diferente, por lo que existen muchos problemas que podrían haberse evitado en el proceso de escritura del código, que solo se pueden descubrir mediante alarmas online.
Recientemente, el servidor Linux en las dos antenas descubrió que la CPU del proceso java se ha disparado. La CPU del nuevo paquete aumentará lentamente después de un tiempo. Se siente muy extraño. No había tal situación antes. Debería ser causado por el nuevo código escrito por el desarrollador. La solución de problemas es la siguiente:
Uno usa el comando superior
Usar comando superior
Los resultados son los siguientes:
Después de un tiempo, continúe viendo la parte superior
Uso de CPU de dos hilos específicos de consulta
Utilice el comando ps -mp 5910 -o THREAD, tid, time
Los resultados son los siguientes:
Se puede ver que el proceso 5910 ha producido una gran cantidad de subprocesos y continúa verificando la ejecución específica de este subproceso.
Primero obtenga el número decimal mediante printf "% xn" 18082
El resultado es 46a2
Tres usan jstack para ver subprocesos específicos
Utilice el comando jstack 5910 | grep 46a2-a 100
Los resultados son los siguientes:
Les pedí a los desarrolladores que pensaran dónde el código que quería escribir usa un grupo de subprocesos, y así sucesivamente. Realmente existe tal código. Miré el código juntos y encontré el problema.
Nota: El siguiente código es un código de simulación
El problema es que el while (verdadero) en el método createTask entra en un bucle infinito, que es causado por la generación continua de subprocesos (el subproceso anterior no se libera y este último continúa generándose).
De hecho, el asunto no ha terminado aquí. Vi que el código usa newCachedThreadPool. Crea un grupo de subprocesos almacenable en caché. Si la longitud del grupo de subprocesos excede las necesidades de procesamiento, los subprocesos inactivos se pueden reciclar de manera flexible. Si no hay reciclaje, se crea un nuevo subproceso. En otras palabras, si el subproceso principal envía tareas a una velocidad mayor que las tareas de procesamiento en el grupo de subprocesos, CachedThreadPool continuará creando nuevos subprocesos. En casos extremos, CachedThreadPool agotará los recursos de la CPU debido a la creación de demasiados subprocesos. Por lo tanto, esta parte también debe tenerse en cuenta primero y luego optimizarse más tarde.