なぜi ++はアトミックではないのですか？

なぜi++Javaではアトミックではないのですか？

Javaを少し深くするために、スレッド内のループが実行される頻度を数えようとしました。

だから私は

private static int total = 0;

メインクラスで。

2つのスレッドがあります。

• スレッド1：プリント System.out.println("Hello from Thread 1!");
• スレッド2：プリント System.out.println("Hello from Thread 2!");

そして、スレッド1とスレッド2によって印刷された行を数えますが、スレッド1の行+スレッド2の行は、印刷された行の総数と一致しません。

これが私のコードです：

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.logging.Level;
import java.util.logging.Logger;

public class Test {

    private static int total = 0;
    private static int countT1 = 0;
    private static int countT2 = 0;
    private boolean run = true;

    public Test() {
        ExecutorService newCachedThreadPool = Executors.newCachedThreadPool();
        newCachedThreadPool.execute(t1);
        newCachedThreadPool.execute(t2);
        try {
            Thread.sleep(1000);
        }
        catch (InterruptedException ex) {
            Logger.getLogger(Test.class.getName()).log(Level.SEVERE, null, ex);
        }
        run = false;
        try {
            Thread.sleep(1000);
        }
        catch (InterruptedException ex) {
            Logger.getLogger(Test.class.getName()).log(Level.SEVERE, null, ex);
        }
        System.out.println((countT1 + countT2 + " == " + total));
    }

    private Runnable t1 = new Runnable() {
        @Override
        public void run() {
            while (run) {
                total++;
                countT1++;
                System.out.println("Hello #" + countT1 + " from Thread 2! Total hello: " + total);
            }
        }
    };

    private Runnable t2 = new Runnable() {
        @Override
        public void run() {
            while (run) {
                total++;
                countT2++;
                System.out.println("Hello #" + countT2 + " from Thread 2! Total hello: " + total);
            }
        }
    };

    public static void main(String[] args) {
        new Test();
    }
}

i++原子性はの大部分の用途には存在しない特別な要件であるため、Javaではおそらく原子的ではありませんi++。この要件にはかなりのオーバーヘッドがあります。インクリメント操作をアトミックにすることには大きなコストがかかります。これには、通常の増分で存在する必要のないソフトウェアレベルとハードウェアレベルの両方での同期が含まれます。

i++非アトミックなインクリメントがを使用して実行されるように、アトミックなインクリメントを実行するように設計および文書化されているはずの引数を作成できますi = i + 1。ただし、これはJavaとCおよびC ++の間の「文化的な互換性」を壊します。同様に、Cライクな言語に精通しているプログラマーが当たり前とする便利な表記を取り除き、限られた状況でのみ適用される特別な意味を与えます。

のような基本的なCまたはC ++コードfor (i = 0; i < LIMIT; i++)はJavaに次のように変換されfor (i = 0; i < LIMIT; i = i + 1)ます。アトミックを使用するのは不適切なためi++です。さらに悪いことに、Cや他のCのような言語からJavaに来るプログラマーはi++とにかく使用してしまい、アトミックな命令を不必要に使用することになります。

マシンインストラクションセットレベルでも、通常、インクリメントタイプの操作はパフォーマンス上の理由からアトミックではありません。x86では、特別な命令「lock prefix」を使用して、inc上記と同じ理由で、命令をアトミックにする必要があります。Ifはinc常にアトミックた非アトミックINCが必要な場合に、それが使用されることはありませんでしょう。プログラマーとコンパイラーは、ロード、1の追加、およびストアを行うコードを生成します。

一部の命令セットアーキテクチャでは、アトミックがないincか、おそらくまったくありませんinc。MIPSでアトミックincを行うには、lland sc：load-linkedとstore-conditional を使用するソフトウェアループを記述する必要があります。load-linkedは単語を読み取り、単語が変更されていない場合はstore-conditionalが新しい値を保存します。そうでない場合は失敗します（検出されて再試行が発生します）。

i++ 2つの操作が含まれます。

1. 現在の値を読み取る i
2. 値をインクリメントして割り当てます i

2つのスレッドがi++同時に同じ変数を実行すると、両方が同じ現在の値を取得し、iそれをインクリメントしてに設定するためi+1、2つではなく1つのインクリメントが得られます。

例：

int i = 5;
Thread 1 : i++;
           // reads value 5
Thread 2 : i++;
           // reads value 5
Thread 1 : // increments i to 6
Thread 2 : // increments i to 6
           // i == 6 instead of 7

重要なのは、JVMのさまざまな実装が言語の特定の機能を実装しているかどうかにかかわらず、JLS（Java言語仕様）です。JLSは15.14.2節で++後置演算子を定義しています。これは、iaは「値1が変数の値に追加され、合計が変数に戻されて格納される」と述べています。マルチスレッドや原子性について言及または示唆するところはどこにもありません。これらに対して、JLSは揮発性で同期化されたものを提供します。さらに、パッケージjava.util.concurrent.atomicがあります（http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/atomic/package-summary.htmlを参照）

なぜi ++はJavaでアトミックではないのですか？

インクリメント操作を複数のステートメントに分割しましょう：

スレッド1＆2：

1. 合計のメモリからの値のフェッチ
2. 値に1を加算します
3. メモリに書き戻す

同期がない場合は、スレッド1が値3を読み取って4に増やしたが、書き戻していないとしましょう。この時点で、コンテキストの切り替えが発生します。スレッド2は値3を読み取り、値をインクリメントし、コンテキストスイッチが発生します。両方のスレッドが合計値を増やしましたが、それでも4-競合状態になります。

i++ 3つの操作を含むステートメントです。

1. 現在の値を読み取る
2. 新しい値を書き込む
3. 新しい値を保存

これらの3つの操作は、単一のステップで実行されることを意図してi++おらず、つまり複合操作ではありません 。結果として、複数のスレッドが単一の非複合操作に関係している場合、あらゆる種類のことがうまくいかない可能性があります。

次のシナリオを検討してください。

時間1：

Thread A fetches i
Thread B fetches i

時間2：

Thread A overwrites i with a new value say -foo-
Thread B overwrites i with a new value say -bar-
Thread B stores -bar- in i

// At this time thread B seems to be more 'active'. Not only does it overwrite 
// its local copy of i but also makes it in time to store -bar- back to 
// 'main' memory (i)

時間3：

Thread A attempts to store -foo- in memory effectively overwriting the -bar- 
value (in i) which was just stored by thread B in Time 2.

Thread B has nothing to do here. Its work was done by Time 2. However it was 
all for nothing as -bar- was eventually overwritten by another thread.

そして、そこにあります。競合状態。

それi++がアトミックではない理由です。もしそうなら、これは何もfetch-update-store起こらず、それぞれがアトミックに起こります。それがまさにそのAtomicIntegerためであり、あなたの場合にはおそらくぴったり合うでしょう。

PS

それらすべての問題をカバーする優れた本、そしていくつかはこれです： Javaの並行性の実践

JVMでは、増分には読み取りと書き込みが含まれるため、アトミックではありません。

操作i++がアトミックである場合は、その値を読み取る機会がありません。これはまさにi++（を使用する代わりに++i）使用したいことです。

たとえば、次のコードを見てください。

public static void main(final String[] args) {
    int i = 0;
    System.out.println(i++);
}

この場合、出力は次のようになります0 （インクリメントをポストするため（たとえば、最初に読み取り、次に更新するため））。

これは、操作をアトミックにすることができない理由の1つです。これは、値を読み取って（そしてそれに対して何かを行う必要があります）、次に値を更新する必要があるためです。

もう1つの重要な理由は、ロックのために、通常、何かをアトミックに実行すると時間がかかることです。人々がアトミックな操作をしたいというまれなケースで、プリミティブに対するすべての操作に少し長くかかるのはばかげたことでしょう。彼らは追加した理由ですAtomicIntegerし、他の言語へのアトミックなクラス。

2つのステップがあります。

1. メモリから私をフェッチ
2. i + 1をiに設定

したがって、アトミック操作ではありません。thread1がi ++を実行し、thread2がi ++を実行する場合、iの最終値はi + 1になります。

並行性（Threadクラスなど）は、Java v1.0の追加機能です。i++その前にベータ版で追加されました。そのため、（多かれ少なかれ）元の実装では、まだありそうです。

変数を同期させるのはプログラマの責任です。これに関するOracleのチュートリアルを確認してください。

編集：明確にするために、i ++はJavaよりも古くからある明確に定義された手順であり、そのためJavaの設計者はその手順の元の機能を維持することを決定しました。

++演算子はB（1969）で定義されたもので、Javaおよびスレッド化よりも少し前から存在していました。