最大スレッド数 = 16 のワーク マネージャーを定義しましたが、Growable ではありません。ただし、ログを見ると、スレッド番号が 180 以上あることがわかります。
[WorkManager.Transformer : 180]
[WorkManager.Transformer : 181]
[WorkManager.Transformer : 182]
[WorkManager.Transformer : 183]
これが原因で、スレッドがリソースを待機して枯渇し、180 秒後に JDBC ConnectionWaitTimeoutException をスローしていると思われます。
最大制限が 16 に設定されていると、非常に多くのスレッドが生成されるのはなぜですか。他に何を確認できますか?
スレッド インデックスは、サーバーの存続期間中にそのスレッド プール用に作成されたスレッドの総数であり、現在アクティブなスレッドの数を必ずしも示しているわけではありません。プールの最小値と最大値が同じでない場合、プールは一定期間使用されなかった後、構成された最小値までスレッドを削除し、需要がその最小レベルを超えた場合に新しいスレッドを作成します。新しく作成されたスレッドのインデックスは、まだ使用されていない次の番号です。
たとえば、最小サイズが 1 で最大サイズが 5 のプールがあり、それに 5 つの作業項目を同時にディスパッチすると、「Pool : 0」から「Pool : 4」という名前のスレッドが作成されます。これらの作業項目が終了すると、最小プール サイズで指定されているように、しばらくすると 1 つを除くすべての作業項目が削除されます。再び 5 つの作業項目をプールにディスパッチすると、「Pool : 5」から「Pool : 8」という名前の 4 つのスレッドが作成されますが、最大のインデックス番号が 8 であっても、アクティブなスレッドは 5 つしかありません。
これが実際には当てはまらないことが懸念される場合は、プロセスから javacore を収集 (kill -3 <pid>またはサーバーの管理コンソールから要求) し、名前に「WorkManager.Transformer」が含まれるスレッドの数を単純に数えることができます - I 16以下になると思います。javacore は、リソースの問題の原因を特定するのにも役立ちます。スレッドのスタックと、スレッドが待機しているロックやその他のリソースを確認できるからです。