Ajuste real de JVM
Descripción del problema
Existe un servicio de texto a voz en un determinado proyecto, que utiliza el servicio de conversión de voz de HKUST iFLYTEK, que requiere un servicio tripartito. Debido a que su servicio de conversión es una operación que requiere mucho tiempo, la demostración oficial usa WebSocket para las operaciones de conversión de datos. El grupo de subprocesos se utiliza en el proyecto para realizar llamadas. Al mismo tiempo, la síntesis de voz de iFLYTEK tiene un límite de longitud. El oficial es [8000 bytes, aproximadamente 2000 caracteres chinos], por lo que debe sintetizarse en segmentos.
Cierto día, el cliente respondió que no se podía reproducir la voz. Después de revisar el registro de servicio, fue porque el servicio comprado venció, el cliente volvió a comprar los servicios restantes, se cambiaron los parámetros y no se pudieron utilizar los parámetros anteriores. . Después de cambiar los parámetros y actualizar la implementación, el servicio vuelve a la normalidad. Después de unos días, el cliente respondió que la voz no se podía volver a reproducir. Después de revisar el registro, se encontró que la mayoría de ellos tuvieron éxito y algunos fallaron.
Proceso de tuning
Al mirar el registro, se encontró que algunas de las fallas fueron causadas por fallas de conexión, y el número de proceso de aplicación correspondiente se encontró a través de jps.
Luego, verifique la tasa de ocupación de la CPU y la memoria a través del PID de alta potencia, y todas son ocupación normal.
Debido a que utiliza el grupo de subprocesos, se sospecha que el grupo de subprocesos está lleno. Después de comprobar el grupo de subprocesos con el pid de la pila, se encuentra que está lleno.
"OkHttp ConnectionPool" # 48 daemon prio = 5 os_prio = 0 tid = 0x00007f8d90002800 nid = 0x2a7a en Object.wait () [0x00007f8dea5a5000] java.lang.Thread.State: TIMED_WAITING (en el monitor de objetos) en java.wait.ObjectING (Método nativo) en java.lang.Object.wait (Object.java:460) en okhttp3.internal.Util.waitMillis (Util.kt: 536) en okhttp3.internal.Util.lockAndWaitNanos (Util.kt: 522) - bloqueado <0x000000076e9394f8> (a okhttp3.internal.connection.RealConnectionPool) en okhttp3.internal.connection.RealConnectionPool $ cleanupRunnable $ 1.run (RealConnectionPool.kt: 49) en java.util.concurrent.ThreadrPoolvaExecutor11 ) en java.util.concurrent.ThreadPoolExecutor $ Worker.run (ThreadPoolExecutor.java:624) en java.lang.Thread.run (Thread.java:748) "pool-1-thread-3" # 46 prio = 5 os_prio = 0 tid = 0x00007f8dd4013000 nid = 0x2a78 esperando en condición [0x00007f8deaaa8000] java.lang.Thread. Estado: WAITING (estacionamiento) en sun.misc.Unsafe.park (método nativo) : estacionamiento para esperar <0x000000076ea3d738> (un java.util.concurrent.CountDownLatch $ Sync) en java.util.concurrent.locks.LockSupport.park (LockSupport.java:175) en java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt en java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterrupt. concurrent.CountDownLatch.await (CountDownLatch.java:231) en java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptInterrupt en java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptbly (AbstractQueuedSynchronizer.java:1304) en com.baiying.trstts.factory.XfTts.getPcm (XfTts.java:206) en com.baiying.trstts.factory (XfTts.java:236) en com.baiying.trstts.controller.TextToSpeechControllerV3.lambda $ text2Speech $ 0 (TextToSpeechControllerV3.java:56) en com.baiying.trstts.controller.TextToSpeechControllerV3 / $$ Lambda90 $ 426.r $$ Lambda90 ) en java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1149) en java.util.concurrent.ThreadPoolExecutor $ Worker.run (ThreadPoolExecutor.java:624) en java.lang.Thread.run: (Thread.java.run 748)
A través de la información de la excepción, se puede ver que CountDownLatch bloqueó todo el subproceso, lo que provocó que no terminara. A través del recorrido del código, se encontró que countDown () despierta el subproceso solo cuando el programa termina normalmente y continúa para ejecutar hacia abajo. El subproceso no se despertará, por lo que countDown () se agrega al programa para reactivar el subproceso cuando falla. Después de que el programa se vuelve a implementar, el programa es normal.
Para evitar problemas, esta vez se controló el registro del programa y se volvieron a convertir los artículos fallidos. Aunque el hilo puede finalizar normalmente, la conversión aún falla. Después de un análisis estricto del texto y varias pruebas de conversión, un breve fragmento de El texto fue interceptado. Después de observarlo por un tiempo, no se encontró ninguna anomalía. Después de verificarlo a través del software hexadecimal, descubrí que los dos caracteres son diferentes. Ambos caracteres son espacios, pero el primer espacio es un método de entrada de ancho medio. el espacio bajo el sistema hexadecimal es 20, y el espacio bajo el método de entrada de ancho completo es E38080. Luego modifique el programa para eliminar los espacios bajo el método de entrada de ancho completo, y realice la conversión nuevamente, y el servicio es normal.
