1

ディレクトリ内の複数のJARからクラスを動的にロードするコードがいくつかあります。JAR内のコードは信頼できないため、メインアプリケーションを「サンドボックス化」することで、コーディングが不十分な動的クラスや悪意のある動的クラスからメインアプリケーションを保護したいと思います。私がやろうとしていることの1つは、信頼できないコードの実行を「タイムボックス化」し、時間がかかりすぎる場合はコードを強制終了することです(たとえば、無限ループでスタックしているため)。CallableとFutureを使用してこれを実装しようとしています。これは、タスクを並行して実行するためではなく(実行しない)、戻り値を提供し、例外をキャプチャし、実行中のタスクをキャンセルするために行われた作業を利用するためです。ただし、いくつかのテストコードで実行すると、Future.cancel(true)を呼び出してもタスクがキャンセルされないようです。

StackOverflowでこれが発生する理由についていくつかの質問(これなど)を見てきましたが、答えは常に同じです。cancel(true)は、Callableを実行しているスレッドでinterrupt()を呼び出すことで機能します。これには、キャンセルが必要です。キャンセルが有効になる前のinterrupt()ible操作(Thread.sleep()など)のタスクブロック。私は実行中のコードを制御していないので、それが実行される保証はありません。したがって、キャンセルしたかどうかはわかりません。

動的にロードされたコードを実行し、後で進行中のコードを強制終了して、interrupt()ible操作でブロックされない場合でも確実に停止する方法はありますか?

// Assume: ExecutorService pool, Callable<T> task,
//  long timeout, TimeUnit timeUnit
Future<T> future = pool.submit(task);
T result;

try {
    result = future.get(timeout, timeUnit);
    // do something with result
} catch (TimeoutException ex) {
    future.cancel(true);
    // handle timeout
} catch (ExecutionException ex) {
    // handle exeception thrown by task
} catch (InterruptedException ex) {
    // handle InterruptedException
}
4

2 に答える 2

3

キャンセル、つまりスレッド中断のメカニズムは基本的に協調的であり、不正なタスクを中断するためにできることは何もありません。多くの理由で非常に危険なあなたの唯一の選択肢は、Thread.stop()彼らにすることです。

于 2012-07-24T19:56:06.047 に答える
1

と の次にThread.stopThread.destroy究極のサンドボックス化のために、 を使用してサブプロセスで JVM 全体を生成できますProcess p = Runtime.getRuntime().exec( cmd );。プロセスは実際に破壊することができますProcess.destroy if necessary.

プロセスの作成を容易にするには、 を使用しますProcessBuilder。また、利用可能なチュートリアル (これはフランス語です) を参照して、プロセスを実行し、完了まで待ち (を使用waitFor)、ストリームを管理します。

ps ドキュメントを pdf に変換する必要がある製品で動作しているのを見てきました。ps ファイルをダンプし、 を実行ps2pdfして、出力ファイルを読み取っていました。

長所/短所Process:

  • (+) 別のプロセスへの実際のサンドボックス化
  • (-) JVM 間の通信が扱いにくい
  • (-) アプリの展開が複雑になります (JVM のパス、オプション、現在のディレクトリなど)。

Thread.stopand (実際に実装されているかどうかはわかりませThread.destroyん)は、ロックの取得と解放に関して安全ではないため、お勧めできません。Thread.stop、Thread.suspend、Thread.resume、および Runtime.runFinalizersOnExit が非推奨になる理由を必ずお読みください。別のスレッドで実行されている信頼できないモジュールがアプリケーションのロックを台無しにしない場合、最悪の場合でも独自のロックを台無しにする場合Thread.stopでも、最良のオプションである可能性があります。

長所/短所Thread.stop

  • (+) 使いやすい
  • (+) 信頼できるコードと信頼できないコードの間の通信は簡単です
  • (-) 非推奨
  • (-) 最初に評価しなければならない非常に特殊な状況では安全ではない可能性があります
于 2012-07-27T08:25:58.240 に答える