問題タブ [jsr166]

デフォルトのセキュリティ マネージャーでは、ExecutorService (この場合はThreadPoolExecutor ) を作成すると、それをシャットダウンできず、shutdown()呼び出すだけですぐに終了しますcheckPermission("modifyThread")。

サンJDK:

$ java -Djava.security.manager 現在のスレッド: Thread[main,5,main] Exception in thread "main" java.security.AccessControlException: access denied (java.lang.RuntimePermission modifyThread) at java.security.AccessControlContext.checkPermission (AccessControlContext.java:323) で java.security.AccessController.checkPermission(AccessController.java:546) で java.lang.SecurityManager.checkPermission(SecurityManager.java:532) で java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor. java:1094) で A.main(A.java:22)

OpenJDK:

$ java -Djava.security.manager 現在のスレッド: Thread[main,5,main] Exception in thread "main" java.security.AccessControlException: access denied (java.lang.RuntimePermission modifyThread) at java.security.AccessControlContext.checkPermission (AccessControlContext.java:342) で java.security.AccessController.checkPermission(AccessController.java:553) で java.lang.SecurityManager.checkPermission(SecurityManager.java:549) で java.util.concurrent.ThreadPoolExecutor.checkShutdownAccess(ThreadPoolExecutor. java:711) で java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:1351) で A.main(A.java:22) で

どうして？？？？？？？自分だけが制御するスレッド プールを作成してシャットダウンすると、セキュリティにどのような影響がありますか? これは実装のバグですか、それとも何か不足していますか?

ExecutorService.shutdownの仕様を見てみましょう...

以前に送信されたタスクが実行される順序どおりのシャットダウンを開始しますが、新しいタスクは受け入れられません。すでにシャットダウンされている場合、呼び出しによる追加の効果はありません。

例外: SecurityException - セキュリティ マネージャが存在し、この ExecutorService をシャットダウンすると、RuntimePermission("modifyThread") を保持していないか、セキュリティ マネージャの checkAccess メソッドがアクセスを拒否するために、呼び出し元が変更を許可されていないスレッドを操作する可能性がある場合。

これは... とてつもなく曖昧です。この仕様では、ExecutorService のライフサイクル中に作成される「システム スレッド」については何も述べていません。さらに、独自のスレッドを提供できるため、その際に「システム スレッド」が関与してはならないことが証明されています。(上記のサンプルソースで行ったように)

Java SE の実装者は、 がshutdownをレイズすることが可能であることを認識したように感じられるSecurityExceptionので、「オーケー、準拠のためにここにランダムなセキュリティ チェックを追加します」というようなものでした...

問題は、OpenJDK ソース (openjdk-6-src-b20-21_jun_2010) を読むと、スレッドを作成する唯一の方法は、提供された ThreadFactory を呼び出すことであることがわかります(これは、テストケースでは決して呼び出されません。作業を作成せず、prestartCoreThreadまたはpreStartAllCoreThreadsを呼び出しません)。したがって、セキュリティ チェックは、OpenJDK の ThreadPoolExecutor で明らかな理由もなく行われます (sun-jdk-1.6 で行われますが、ソースはありません)。

checkShutdownAccess何かをする前に呼び出されます...

ご覧のとおり、無条件にセキュリティ マネージャーを呼び出しますcheckPermission(shutdownPerm).... shutdownPerm は次のように定義されています... private static final RuntimePermission shutdownPerm = new RuntimePermission("modifyThread");

...システムスレッドmodifyThreadへのアクセスを意味するため、私が知る限り、これはまったく意味がありません。また、ここではシステムスレッドが実行されていません。実際、作業や事前開始を送信しなかったため、スレッドはまったくありません、スレッドがあったとしても、.を渡したので、それらは私のスレッドになります。システムスレッドが関与している場合（関与していない場合）、.ThreadFactorySecurityException

基本的に、システム スレッドへのアクセスをチェックする行を削除できないのはなぜですか? それを必要とするセキュリティ上の意味はありません。そして、他の誰もこの問題に出くわしたのはどうしてですか??? への呼び出しを変更することでこの問題を「解決」した問題トラッカーの投稿を見たことがありますがshutdownNow、shutdown明らかに修正されませんでした。

Brian Goetzは、fork-joinに関する素晴らしい記事をhttp://www.ibm.com/developerworks/java/library/j-jtp03048.htmlに書いています。その中で、彼はフォークジョインメカニズムを使用したマージソートアルゴリズムをリストしています。このアルゴリズムでは、配列の両側で並列にソートを実行し、結果をマージします。

アルゴリズムは、同じ配列の2つの異なるセクションで同時にソートします。可視性を維持するためにAtomicIntegerArrayまたはその他のメカニズムが必要ないのはなぜですか？一方のスレッドがもう一方のスレッドによって行われた書き込みを確認するという保証はありますか、それともこれは微妙なバグですか？フォローアップとして、ScalaのForkJoinSchedulerもこの保証をしますか？

ありがとう！

Producer と Consumer の 2 つのタスク間でオブジェクト (この場合は int の配列) を交換しようとする、非常に単純な問題があります。Producer クラスは int の配列を生成し、それを Exchanger オブジェクトを使用して Consumer 配列 (空の配列) と交換しようとします。しかし、うまくいかないようです: Consumer が配列を出力しようとしても、何も得られません。

Producer で行のコメントを外すと、生成された数値がまだそこにあることがわかります。では、なぜオブジェクトを交換しないのでしょうか?

BlockingQueue/LinkedBlockingQueue と、jsr166y および Java 7 の新しい TransferQueue/LinkedTransferQueue タイプの違いについて、少し混乱しています。

JavaAtomicReferenceFieldUpdaterドキュメントから：

このクラスのメソッドの保証は、compareAndSet他のアトミッククラスよりも弱いことに注意してください。このクラスは、フィールドのすべての使用がアトミックアクセスの目的に適切であることを保証できないため、およびの他の呼び出しに関してのみ、アトミック性と揮発性セマンティクスを保証できcompareAndSetますset。

つまり、通常の揮発性書き込みをと一緒に実行することはできませんが、代わりcompareAndSetに使用する必要があります。setについては何も言及していませんget。

それは、同じ原子性の保証で揮発性フィールドをまだ読み取ることができることを意味します-setまたはの前にすべての書き込みcompareAndSetがあり、揮発性フィールドを読み取ったすべての人に表示されますか？

または、フィールドでの揮発性読み取りgetの代わりにを使用する必要がありますか？AtomicReferenceFieldUpdater

参考文献をお持ちの場合は投稿してください。

ありがとうございました。

編集：

Java Concurrency in Practiceから、彼らが言うのは次のことだけです。

アップデータクラスのアトミック性の保証は、基になるフィールドが直接変更されないことを保証できないため、通常のアトミッククラスよりも弱くなります。compareAndSetメソッドと算術メソッドは、アトミックフィールドアップデータメソッドを使用する他のスレッドに関してのみアトミック性を保証します。

繰り返しますが、他のスレッドがこれらの揮発性フィールドを読み取る方法については言及されていません。

また、「直接変更」は通常の揮発性書き込みであると想定するのは正しいですか？

Scala 2.10に移行するということですか、それともjsr166yが別途リリースされるということですか？...または、他の何か？

Java 1.6 でいくつかのJSR166クラスを使用していjava.util.concurrentます。私は OSX を使用していますが、最終的には Linux で動作することを期待しています。

この環境変数を設定すると、プロジェクトを実行できます。

ここの指示に従って、設定を my に入れてみましたpom.xml：

残念ながら、これにより、 が見つからないというエラーが発生しましたjava.lang。classes.jar（明らかに OSX のバージョンのrt.jar）への参照を追加するとbootclasspath、そのエラーを修正できますが、最初の場所に戻るだけです。

この引数を正しく使用するには、maven をどのように設定すればよいですか?