そのため、VisualVMを使用してアプリケーションのプロファイリングを行っていました。
MySQLの相互作用についてホットスポットにぶつかりました。私が最初に考えたのは、ホットスポットは、アプリケーションがIOの後に待機している時間を示しているということでした。ただし、プロファイリングレポートでは、VisualVMには「Time」と「Time（cpu）」の2つの列があります。この用語は間違って使用されている可能性がありますが、自己時間（cpu）列はIO時間を除外していると思いました。さらにデバッグした後、ホットスポットがMySQLドライバーのjava.net.SocketInputStream.read（）およびCPUのコストがかからないその他のIOにあるため、仮定が間違っており、IO時間を示していると結論付けました。
だから、私の質問は、なぜvisualvmがSocketInputStream.read（）をCPU時間として報告するのですか？
スレッド アクティビティを監視している間、ネイティブ コールは常に RUNNABLE 状態になります。これはおそらく、ネイティブ コールがスリープしているか、実際に何かを実行しているかを JVM が認識できないためです。したがって、RUNNABLE 状態で経過した時間が CPU 時間としてカウントされます。
この非常に長いスレッドは、小さな書き込みが問題を引き起こしている可能性があると主張しています。読む価値はありますが、それについて何ができるかわかりません。あなたは何ができますか？小さなフェッチ サイズを使用していないことを確認してください。これは小さな書き込みではなく、同じ問題につながる小さな読み取りを提供します。クライアントまたはサーバー用にさまざまなプラットフォームを試すことができます。このバグには次のようなコメントがあります。
「Solaris と Linux の間で I/O バッファがいっぱいになる速さ (したがって、ReadAheadInputStream.fill() への呼び出しの数) について、非常に異なる動作が見られました。これは、利用可能なものを読み取り、必要でない限りブロックしないためです。利用可能なものよりも多くを読んでください）。」
SocketInputStream.read() は、反対側からデータが利用可能になるまでブロックします。そのため、データベースからの応答が遅くなる可能性があります。