非最終フィールドの同期

Question 1

非最終クラスフィールドで同期するたびに警告が表示されます。コードは次のとおりです。

public class X  
{  
   private Object o;  

   public void setO(Object o)  
   {  
     this.o = o;  
   }  

   public void x()  
   {  
     synchronized (o) // synchronization on a non-final field  
     {  
     }  
   }  
 }

だから私は次のようにコーディングを変更しました：

 public class X  
 {  

   private final Object o;       
   public X()
   {  
     o = new Object();  
   }  

   public void x()  
   {  
     synchronized (o)
     {  
     }  
   }  
 }

上記のコードが非最終クラスフィールドで同期する適切な方法であるかどうかはわかりません。非最終フィールドを同期するにはどうすればよいですか？

Question 2

まず第一に、より高いレベルの抽象化で並行性の問題に対処するために本当に一生懸命努力することをお勧めします。つまり、ExecutorServices、Callables、Futuresなどのjava.util.concurrentのクラスを使用して解決します。

そうは言っても、非最終フィールド自体で同期することに何の問題もありません。オブジェクト参照が変更された場合、コードの同じセクションが並行して実行される可能性があることに注意する必要があります。つまり、あるスレッドが同期ブロックでコードを実行し、誰かが呼び出したsetO(...)場合、別のスレッドが同じインスタンスで同じ同期ブロックを同時に実行できます。

排他的アクセスが必要なオブジェクト（または、さらに良いことに、それを保護するための専用オブジェクト）で同期します。

Question 3

同期されたブロックが一貫した方法で実際に同期されなくなったため、これは実際には良い考えではありません。

同期されたブロックが、一度に1つのスレッドのみが一部の共有データにアクセスすることを保証することを目的としていると仮定して、次のことを考慮してください。

スレッド1は同期ブロックに入ります。イェーイ-共有データへの排他的アクセスがあります...
スレッド2はsetO（）を呼び出します
スレッド3（またはまだ2 ...）が同期ブロックに入ります。イーク！共有データへの排他的アクセス権があると考えていますが、スレッド1はまだそれを使っています...

なぜこれを実現したいのですか？おそらく、それが理にかなっている非常に特殊な状況がいくつかあります...しかし、私が満足する前に、特定のユースケースを（上記のシナリオの種類を軽減する方法とともに）提示する必要がありますそれ。

Question 4

Johnのコメントの1つに同意します。変数の参照が変更された場合の不整合を防ぐために、非最終変数にアクセスするときは常に最終ロックダミーを使用する必要があります。したがって、どのような場合でも、最初の経験則として：

ルール＃1：フィールドが非ファイナルの場合、常に（プライベート）ファイナルロックダミーを使用します。

理由＃1：ロックを保持し、変数の参照を自分で変更します。同期ロックの外側で待機している別のスレッドは、保護されたブロックに入ることができます。

理由＃2：ロックを保持し、別のスレッドが変数の参照を変更します。結果は同じです。別のスレッドが保護されたブロックに入ることができます。

ただし、ファイナルロックダミーを使用する場合は、別の問題があります。非同期オブジェクトは、synchronize（object）を呼び出すときにのみ、RAMと同期されるため、間違ったデータを取得する可能性があります。したがって、2番目の経験則として：

ルール＃2：非最終オブジェクトをロックするときは、常に次の両方を行う必要があります。RAM同期のために、最終ロックダミーと非最終オブジェクトのロックを使用します。（唯一の代替手段は、オブジェクトのすべてのフィールドを揮発性として宣言することです！）

これらのロックは「ネストされたロック」とも呼ばれます。それらを常に同じ順序で呼び出す必要があることに注意してください。そうしないと、デッドロックが発生します。

public class X {
    private final LOCK;
    private Object o;

    public void setO(Object o){
        this.o = o;  
    }  

    public void x() {
        synchronized (LOCK) {
        synchronized(o){
            //do something with o...
        }
        }  
    }  
}

ご覧のとおり、2つのロックは常に一緒に属しているため、同じ行に直接書き込みます。このように、10個のネストロックを実行することもできます。

synchronized (LOCK1) {
synchronized (LOCK2) {
synchronized (LOCK3) {
synchronized (LOCK4) {
    //entering the locked space
}
}
}
}

synchronized (LOCK3)別のスレッドのように内部ロックを取得しただけでは、このコードは壊れないことに注意してください。しかし、次のような別のスレッドを呼び出すと、壊れます。

synchronized (LOCK4) {
synchronized (LOCK1) {  //dead lock!
synchronized (LOCK3) {
synchronized (LOCK2) {
    //will never enter here...
}
}
}
}

非最終フィールドを処理する際のこのようなネストされたロックを回避する回避策は1つだけです。

ルール＃2-代替：オブジェクトのすべてのフィールドを揮発性として宣言します。（ここでは、これを行うことの欠点については説明しません。たとえば、読み取りの場合でもxレベルのキャッシュにストレージを保存できないなどです。）

したがって、aioobeは非常に正しいです。java.util.concurrentを使用するだけです。または、同期に関するすべてを理解し始め、ネストされたロックを使用して自分でそれを行います。;）

非最終フィールドでの同期が失敗する理由の詳細については、私のテストケースをご覧ください：https：//stackoverflow.com/a/21460055/2012947

また、RAMとキャッシュが原因で同期が必要な理由の詳細については、https：//stackoverflow.com/a/21409975/2012947をご覧ください。

Question 5

私はここで正しい答えを見ていません。つまり、それを行ってもまったく問題ありません。

なぜそれが警告なのかさえわかりません、それは何も悪いことではありません。JVMは、あなたが得ることを確認するいくつかのあなたが値を読んだときに有効なオブジェクトバック（またはnull）を、そしてあなたが上で同期させることができる任意のオブジェクト。

使用中に実際にロックを変更する予定がある場合（たとえば、使用を開始する前にinitメソッドから変更するのではなく）、変更する予定の変数を作成する必要がありvolatileます。次に、古いオブジェクトと新しいオブジェクトの両方で同期するだけで、値を安全に変更できます。

public volatile Object lock;

..。

synchronized (lock) {
    synchronized (newObject) {
        lock = newObject;
    }
}

そこ。複雑ではありません。ロック（ミューテックス）を使用したコードの記述は、実際には非常に簡単です。それらなしでコードを書くこと（ロックフリーコード）は難しいことです。

Question 6

編集：したがって、このソリューション（Jon Skeetによって提案された）は、オブジェクト参照が変更されている間、「synchronized（object）{}」の実装のアトミック性に問題がある可能性があります。私は個別に尋ねましたが、エリクソン氏によると、スレッドセーフではありません-参照：同期ブロックに入るのはアトミックですか？。それで、それをしない方法の例としてそれを取りなさい-なぜリンクで;）

synchronized（）がアトミックである場合にどのように機能するかをコードで確認してください。

public class Main {
    static class Config{
        char a='0';
        char b='0';
        public void log(){
            synchronized(this){
                System.out.println(""+a+","+b);
            }
        }
    }

    static Config cfg = new Config();

    static class Doer extends Thread {
        char id;

        Doer(char id) {
            this.id = id;
        }

        public void mySleep(long ms){
            try{Thread.sleep(ms);}catch(Exception ex){ex.printStackTrace();}
        }

        public void run() {
            System.out.println("Doer "+id+" beg");
            if(id == 'X'){
                synchronized (cfg){
                    cfg.a=id;
                    mySleep(1000);
                    // do not forget to put synchronize(cfg) over setting new cfg - otherwise following will happend
                    // here it would be modifying different cfg (cos Y will change it).
                    // Another problem would be that new cfg would be in parallel modified by Z cos synchronized is applied on new object
                    cfg.b=id;
                }
            }
            if(id == 'Y'){
                mySleep(333);
                synchronized(cfg) // comment this and you will see inconsistency in log - if you keep it I think all is ok
                {
                    cfg = new Config();  // introduce new configuration
                    // be aware - don't expect here to be synchronized on new cfg!
                    // Z might already get a lock
                }
            }
            if(id == 'Z'){
                mySleep(666);
                synchronized (cfg){
                    cfg.a=id;
                    mySleep(100);
                    cfg.b=id;
                }
            }
            System.out.println("Doer "+id+" end");
            cfg.log();
        }
    }

    public static void main(String[] args) throws InterruptedException {
        Doer X = new Doer('X');
        Doer Y = new Doer('Y');
        Doer Z = new Doer('Z');
        X.start();
        Y.start();
        Z.start();
    }

}

Question 7

AtomicReferenceはお客様の要件に適しています。

アトミックパッケージに関するJavaドキュメントから：

単一変数でのロックフリーのスレッドセーフプログラミングをサポートするクラスの小さなツールキット。本質的に、このパッケージのクラスは、揮発性の値、フィールド、および配列要素の概念を、次の形式のアトミック条件付き更新操作も提供するものに拡張します。

boolean compareAndSet(expectedValue, updateValue);

サンプルコード：

String initialReference = "value 1";

AtomicReference<String> someRef =
    new AtomicReference<String>(initialReference);

String newReference = "value 2";
boolean exchanged = someRef.compareAndSet(initialReference, newReference);
System.out.println("exchanged: " + exchanged);

上記の例では、自分のものに置き換えStringますObject