JVM tatsächliche Abstimmung
Problembeschreibung
In einem bestimmten Projekt gibt es einen Text-zu-Sprache-Dienst, der den Sprachkonvertierungsdienst von HKUST iFLYTEK verwendet, für den ein Drei-Parteien-Dienst erforderlich ist. Da der Konvertierungsdienst zeitaufwändig ist, verwendet die offizielle Demo WebSocket für Datenkonvertierungsvorgänge. Der Thread-Pool wird im Projekt zum Tätigen von Aufrufen verwendet. Gleichzeitig hat die Sprachsynthese von iFLYTEK eine Längenbeschränkung. Die offizielle ist [8000 Bytes, ungefähr 2000 chinesische Zeichen], daher muss sie in Segmenten synthetisiert werden.
An einem bestimmten Tag antwortete der Kunde, dass die Stimme nicht abgespielt werden konnte. Nach Überprüfung des Serviceprotokolls lag es daran, dass der gekaufte Service abgelaufen war, der Kunde die verbleibenden Services zurückgekauft hatte, die Parameter geändert wurden und die vorherigen Parameter nicht verwendet werden konnten . Nach dem Ändern der Parameter und dem Aktualisieren der Bereitstellung kehrt der Dienst zum Normalzustand zurück. Nach einigen Tagen antwortete der Kunde, dass die Stimme nicht mehr abgespielt werden könne. Nach Überprüfung des Protokolls wurde festgestellt, dass die meisten von ihnen erfolgreich waren und einige fehlschlugen.
Abstimmungsprozess
Beim Betrachten des Protokolls wurde festgestellt, dass einige der Fehler durch Verbindungsfehler verursacht wurden, und die entsprechende Nummer des Anwendungsprozesses wurde über jps gefunden.
Überprüfen Sie dann die Belegungsrate einer CPU und des Speichers über die Top-HP-PID, und alle sind normal belegt.
Da der Thread-Pool verwendet wird, wird vermutet, dass der Thread-Pool voll ist. Nachdem der Thread-Pool mit der Stack-PID überprüft wurde, wird festgestellt, dass er voll ist.
"OkHttp Connection" # 48 Daemon PRIO = 5 os_prio = 0 tid = 0x00007f8d90002800 NID = 0x2a7a in Object.wait () [0x00007f8dea5a5000] java.lang.Thread.State: TIMED_WAITING (auf Objektmonitor) bei java.lang.Object.wait (Native Methode) unter java.lang.Object.wait (Object.java:460) unter okhttp3.internal.Util.waitMillis (Util.kt: 536) unter okhttp3.internal.Util.lockAndWaitNanos (Util.kt: 522) - gesperrt <0x000000076e9394f8> (ein okhttp3.internal.connection.RealConnectionPool) bei okhttp3.internal.connection.RealConnectionPool $ cleanupRunnable $ 1.run (RealConnectionPool.kt: 49) bei java.util.concurrent.ThreadPoolExecutor. ) unter java.util.concurrent.ThreadPoolExecutor $ Worker.run (ThreadPoolExecutor.java:624) at java.lang.Thread.run (Thread.java:748) "pool-1-thread-3" # 46 prio = 5 os_prio = 0 tid = 0x00007f8dd4013000 nid = 0x2a78 wartet unter der Bedingung [0x00007f8deaaa8000] java.lang.Thread. Status: WARTEN (Parken) bei sun.misc.Unsafe.park (native Methode) - Parken, um auf <0x000000076ea3d738> (a java.util.concurrent.CountDownLatch $ Sync) bei java.util.concurrent.locks.LockSupport.park zu warten (LockSupport.java:175) unter java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt (AbstractQueuedSynchronizer.java:836) unter java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInter at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly (AbstractQueuedSynchronizer.java:1304) bei java.util. concurrent.CountDownLatch.await (CountDownLatch.java:231) at com.baiying.trstts.factory.XfTts.getPcm (XfTts.java:206) at com.baiying.trstts (XfTts.java:236) unter com.baiying.trstts.controller.TextToSpeechControllerV3.lambda $ text2Speech $ 0 (TextToSpeechControllerV3.java:56) unter com.baiying.trstts.controller.TextToSpeechControllerVun ) unter java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1149) unter java.util.concurrent.ThreadPoolExecutor $ Worker.run (ThreadPoolExecutor.java:624) unter java.lang.Thread.run: Threadjava: 748)
Anhand der Ausnahmeinformationen wird ersichtlich, dass CountDownLatch den gesamten Thread blockiert hat, wodurch er nicht beendet werden konnte. Durch die exemplarische Vorgehensweise des Codes wurde festgestellt, dass countDown () den Thread nur aufweckt, wenn das Programm normal endet, und fortgesetzt wird Der Thread wird nicht aktiviert, daher wird countDown () zum Programm hinzugefügt, um den Thread zu aktivieren, wenn er fehlschlägt. Nach der erneuten Bereitstellung des Programms ist das Programm normal.
Um Probleme zu vermeiden, wurde das Programmprotokoll dieses Mal überwacht und die fehlgeschlagenen Artikel wurden erneut konvertiert. Obwohl der Thread normal enden kann, schlägt die Konvertierung immer noch fehl Text wurde abgefangen. Nachdem ich ihn eine Weile beobachtet hatte, wurde keine Abnormalität gefunden. Nachdem ich ihn durch eine hexadezimale Software überprüft hatte, stellte ich fest, dass die beiden Zeichen unterschiedlich sind. Beide Zeichen sind Leerzeichen, aber das erste Leerzeichen ist eine Eingabemethode mit halber Breite Das Leerzeichen unter dem Hexadezimalsystem ist 20, und das Leerzeichen unter der Eingabemethode mit voller Breite ist E38080. Ändern Sie dann das Programm, um die Leerzeichen unter der Eingabemethode mit voller Breite zu entfernen, und führen Sie die Konvertierung erneut durch, und der Dienst ist normal.
