スレッドセーフについて

Question

スレッドセーフについて教えてください。

言葉の意味自体は複数のスレッドから制御が走った場合に、データの整合性が取れないものという理解をしています。
以下の、コードにおいてはCouterクラスはスレッドセーフではないという使い方で間違いないでしょうか？
例えば、synchronizedをつけるとこのクラスはスレッドセーフということなのでしょうか？

そもそも、java.util.HashMapはスレッドセーフではないというイメージがよく理解できていません。
staticなクラスのメンバがHashMapであった場合にそのメンバの挙動が保証できないということでしょうか？

public class Counter {

	private int count;

	public Counter() {
		this.count = 0;
	}

	 public void countUp() {
		this.count += 1;
	}

	public int get() {
		return this.count;
	}
}

public class CountUpTask implements Runnable {

	private Counter counter;

	public CountUpTask(Counter c) {
		this.counter = c;
	}

	@Override
	public void run() {

		for (int i = 0; i < 10000; i++) {
			this.counter.countUp();
		}
	}

}

public class CountUpTest1 {

	public static void main(String[] args) throws InterruptedException {

		Counter counter = new Counter();
		CountUpTask c1 = new CountUpTask(counter);

		Thread t1 = new Thread(c1);
		Thread t2 = new Thread(c1);

		t1.start();
		t2.start();

		t1.join();
		t2.join();

		System.out.println(counter.get());

	}

}

Answer 1

少し難解かもしれませんが、スレッドセーフ性に関する議論は記事「Javaの理論と実践: スレッド・セーフの特性について」をお薦めします。書籍Effective Javaでも「スレッド安全性を文書化する」として言及されている話題です。

Comments

[KSwordOfHaste]

記事に「…少し探してみれば、スレッド・セーフなコードの定義として典型的な、でも役には立たない、むしろ説明のようなものが見つかり…」とあり、それはまさに自分が挙げたような例ですね。
本来、この解説にあるような内容を知っておくべきと思いました。

Answer 2

追記: yohhoyさんご指摘により最初の例の不具合(volatileが抜けている)ことがわかりましたので修正いたしました。失礼しました。

追記2: 恥かきついでに自分の考えの間違いの説明を試みます。

1. synchronizedでメソッドは排他できる。
2. countUpが実行の完了時にgetが他のスレッドから呼び出されてもcountUp完了まで待たされる
3. countUpが実行を完了していればフィールドの値は0->2に書き換わる
4. その後getが動けば1が読めることはなく、必ず2が読める**(と考えた)**

例えば、複数のプロセッサが並行して動作している場合に、プロセッサーごとに独立して動作するキャッシュがあったとすると、例え同一空間上のメモリーを参照したとしても、メモリー・フェンスなしではどのタイミングの値が読めるかの保証がないということだと思います。自分はコンパイラーの最適化によって最新の値を常に参照するかどうかという観点でvolatileを考えていたのですが、メモリー・フェンスの動作について把握できていませんでした。

(この解釈にも間違いがあるかも知れません。もしそうならご指摘いただければ非常にありがたいです。)

---

スレッドセーフかどうかは「そのクラス（あるいはそのクラスのインスタンス）」に複数のスレッドから機能にアクセスした際に「矛盾のない結果を保証する」ことを意味します。

ご質問のCounterクラスでいえばcountUpメソッドのみにsynchronizedを付ければスレッドセーフと呼べます。しかしながら・・・

class Counter1 {
  private volatile int count;

  public synchronized void countUp() {
    count++;
    count++;
  }

  public int get() {
    return count;
  }
}

上記の(あまりよい実装ではない)クラスで、countUp()の呼び出しをした場合、getの仕様が「結果が偶数であることを保証する」となっていたならスレッドセーフとはいえなくなります。getの起動タイミングによっては1が返される可能性があるからです。(もちろんcount += 2となっていればgetにsynchronizedは必要なくなります)

また違う例で、

class Value {
  public volatile int value;

  public void set(int value) {
    this.value = value;
  }
}

上記のようなクラスは「valueを参照したらそれ以前の最後のset結果が得られる」ことを保証できます。しかしもしvolatileが付いていなければ保証がなくなり、スレッドセーフとはいえなくなります。例えset呼出し後にvalueを参照したとしても、メモリー・フェンスによるアクセス保証がない場合、あるスレッドでvalueを更新後に別のスレッドで更新後の最新の値が読めるという保証がないからです。(コンパイラーの最適化によって過去のvalueのアクセス結果が使いまわされるということもあるかも知れません。)

---

このように、そのクラスが提供する機能の仕様が「何を保証するか」「状態を変更する機能がどのような実装を採っているか」によって「スレッドセーフの正確な意味や配慮」は微妙に変わると思います。

Comments

[msd]

実例を挙げてのご回答ありがとうございました。
よく分かりました。

[yohhoy]

Counter1クラス実装のcountメンバにはvolatile修飾が必須ですよ。理由は https://www.ibm.com/developerworks/jp/java/library/j-jtp06197.html で解説されています。

このあたりは非常に難解なので、よほどの事情が無い限りは出来合いのクラスを使うか、素直に全部synchronizedメソッドにしたほうが無難ですね...

[KSwordOfHaste]

getにsynchronizedを付けてvolatileを付けなかったときに「最新の値を得られないかも知れないが、少なくとも奇数が返される不具合は発生しない」と判断したため、volatileを省いたのですが、yohhoyさんのご指摘により慌てております。提示いただいた解説をみて「自分の理解に足りていない」という点を見つけられずにいるので本件は自分が質問すべきという気がしてきています。

[KSwordOfHaste]

あ・・・単に、「メモリー・フェンスの動作がないのだからいつの時点の値が見えるかはわからない」ということですね。もしこれで認識があってるならかなり間抜けな話ですね・・・

[KSwordOfHaste]

肝心なことを忘れていました。「ご指摘大変ありがとうございました。」>yohhoyさん

Answer 3

以下の、コードにおいてはCouterクラスはスレッドセーフではないという使い方で間違いないでしょうか？

それで問題ありません。

例えば、synchronizedをつけるとこのクラスはスレッドセーフということなのでしょうか？

Counterクラスにある2つのメソッドcountUp,get両方に付けばおそらくスレッドセーフです(正直自身がない)。

そもそも、java.util.HashMapはスレッドセーフではないというイメージがよく理解できていません。

HashMap<String, Integer>を使って、文字列中に登場する単語を単語ごとに数えるというプログラムを考えると、
複数スレッドを使って数え、そのカウント管理をひとつのHashMapインスタンスを使って行った場合、
上記のCounterクラスと全く同じ問題が生じます。

Comments

[msd]

個別の疑問に回答頂きありがとうございます。
ぼんやりとしか分かっていなかったので助かりました！