一部のOTNフォーラム（https://kr.forums.oracle.com/forums/thread.jspa?messageID=3699989）で、この問題に対する解決策が提供されています。しかし、問題の根本的な原因は説明されていません。以下は、問題の根本的な原因を説明するための私の試みです。
Oracle JDBCドライバーは、安全な方法でOracleサーバーと通信します。ドライバーはjava.security.SecureRandomを使用します 通信を確保するためのエントロピーを収集するクラス。このクラスは、エントロピーを収集するためのネイティブプラットフォームのサポートに依存しています。
エントロピー 暗号化またはランダムデータを必要とするその他の用途で使用するためにオペレーティングシステムまたはアプリケーションによって収集/生成されたランダム性です。このランダム性は、多くの場合、ハードウェアノイズ、オーディオデータ、マウスの動き、または特別に提供されたランダム性ジェネレーターのいずれかから、ハードウェアソースから収集されます。カーネルはエントロピーを収集し、それをエントロピープールとして保存し、オペレーティングシステムのプロセスまたはアプリケーションが特別なファイル / dev / randomを介してランダムな文字データを利用できるようにします。 および/ dev / urandom 。
/ dev / randomからの読み取り 要求されたビット/バイト量でエントロピープールを排出し、暗号化操作でしばしば望まれる高度なランダム性を提供します。エントロピープールが完全に排出され、十分なエントロピーが利用できない場合、 / dev / randomでの読み取り操作 追加のエントロピーが収集されるまでブロックします。このため、 / dev / randomから読み取るアプリケーション ランダムな期間ブロックする可能性があります。
上記とは対照的に、 / dev / urandomからの読み取り ブロックしません。 / dev / urandomからの読み取り もエントロピープールを排出しますが、十分なエントロピーが不足している場合は、ブロックせずに、部分的に読み取られたランダムデータのビットを再利用します。これは、暗号分析攻撃の影響を受けやすいと言われています。これは理論上の可能性であるため、 / dev / urandomから読み取ることはお勧めしません。 暗号化操作のランダム性を収集します。
java.security.SecureRandom クラスは、デフォルトで、 / dev / randomから読み取ります ファイル、したがって時々ランダムな期間ブロックします。ここで、読み取り操作が必要な時間戻ってこない場合、Oracleサーバーはクライアント（この場合はjdbcドライバー）をタイムアウトし、ソケットを最後から閉じることによって通信をドロップします。ブロッキングコールから戻った後、クライアントが通信を再開しようとすると、IO例外が発生します。この問題は、特にエントロピーがハードウェアノイズから収集される場合、どのプラットフォームでもランダムに発生する可能性があります。
OTNフォーラムで提案されているように、この問題の解決策は、 java.security.SecureRandomのデフォルトの動作をオーバーライドすることです。 / dev / urandomからの非ブロッキング読み取りを使用するクラス / dev / randomからの読み取りをブロックする代わりに 。これは、次のシステムプロパティを追加することで実行できます -Djava.security.egd =file：/// dev / urandom JVMに。これはJDBCドライバーなどのアプリケーションには適していますが、暗号化キーの生成などのコア暗号化操作を実行するアプリケーションにはお勧めしません。
他の解決策は、エントロピーを収集するためにハードウェアノイズに依存しない、プラットフォームで利用可能なさまざまなランダムシーダー実装を使用することです。これでも、 java.security.SecureRandomのデフォルトの動作をオーバーライドする必要がある場合があります。 。
Oracleサーバー側でソケットタイムアウトを増やすことも解決策になる可能性がありますが、これを試みる前に、サーバーの観点から副作用を評価する必要があります。