並列処理

アクターモデルでは同期は考慮外？

凪瀬 — Thu, 15 Nov 2007 16:25:00 GMT

オブジェクト指向熱イベントパネルディスカッション検討スレッドでオブジェクト指向から話がそれて並列処理の話になってしまったのですが、そこで出てきたのがアクターモデルというものでした。

さて、Wikipediaの解説などを見ているとマルチスレッド特有の同期の問題について触れていないように思ったわけです。
いや、そもそもアクターモデルでは非同期のメッセージのやり取りがあるわけで、時系列操作は考えてはいけないのでしょうから正しくは分散トランザクションの問題というのが正しいのでしょう。

アクターそれぞれが状態を持つことになるでしょうが、ある「状態」を複数のスレッドで処理する場合、つまり、複数のアクターがあるアクターが持つ単一の「状態」を元になんらかの処理を行う場合、元になる状態が可変であるとシステム全体で情報の不整合が発生しうるということです。

そして、この状態の不整合を起こさないようにどうすればよいかというのが分散トランザクション の関心ごとで別のパラダイムとして議論されているのかな、と思った次第。

いずれにせよ、プログラムをする際にはデータの整合性について考慮しないわけにはいかず、そのための同期処理で苦労するわけなのですが、この苦労は分散トランザクションに答えを求めるのが正しいのかもしれませんね。

SimpleDateFormatでNumberFormatException

凪瀬 — Tue, 30 Oct 2007 21:17:00 GMT

障害報告を受けて調査していると、 SimpleDateFormat#parse()でNumberFormatExceptionが出ていました。

ドキュメントにあるように変換に失敗したときはParseExceptionがthrowされるものだと思っていたので、すわバグパレード行きかと思ったら、どうやらSimpleDateFormatをマルチスレッド環境下で使った場合の問題らしいことが判明。

java.text.SimpleDateFormat はスレッドセーフではないがよくまとまっています。

SimpleDateFormatをマルチスレッド下で使ってはならないというtipsは知っていたのですが、その場合の症状としてNumberFormatExceptionがthrowされることがある、というのは知りませんでした。

WEBで重い処理の進捗を表示する

凪瀬 — Thu, 11 Oct 2007 18:02:00 GMT

Webアプリケーションで時間の掛かる処理をキックする場合、進捗表示をしたくなることがあります。
Threadを立てて裏で処理するようにすれば可能なのですが、いろいろと面倒があるのでざっくり指針を書いてみたいと思います。

HTMLから定期的にアクセスする

進捗状況を知るために、HTML側から定時で繰返しアクセスさせる必要があります。
METAタグを使ってリロードさせる手法が一般的ですね。

<META HTTP-EQUIV="Refresh" CONTENT="5">

上記例では5秒ごとのリロードです。

この方式だとページ全体を読み直すわけですが、格好良くしようと思えばAJAX的手法を使って非同期通信する手法もあります。

とにかく、サーバに低的にアクセスします。これをポーリング(polling)といいます。

サーバ側ではセッションにThreadの管理オブジェクトを保管する

サーバ側ではThreadの管理オブジェクトをセッションに格納して管理します。以下はJavaでのコーディング例。

import java.util.Timer; import java.util.TimerTask; public class ThreadManager extends Thread { /** 状態ステータス */ public enum Status { /** 開始待ち */ READY, /** 実行中 */ RUNNIG, /** 正常終了 */ FINISHED, /** 異常終了 */ ERROR, } /** ポーリングのタイムアウト間隔 */ private static final long TIMER_DELAY = 10000; /** スレッドの状態 */ private volatile Status status; /** 停止用のタイマ */ private Timer timer; /** コンストラクタ */ public ThreadManager() { this.status = Status.READY; // DeamonのTimerを作成 this.timer = new Timer(true); } /** 状態を返す */ public Status getStatus() { return this.status; } /** Thread終了タイマーをリセット */ public void resetTimer() { this.timer.cancel(); this.timer.schedule(this.new Canceler(), TIMER_DELAY); } /** * {@inheritDoc} * @see java.lang.Thread#start() */ @Override public synchronized void start() { this.status = Status.RUNNIG; super.start(); this.resetTimer(); } /** 処理結果を返す */ public Object getData() { // ここではダミー実装なのでnullを返しているが、 // 必要な情報を格納したオブジェクトであるべき return null; } /** エラー結果を返す */ public Object getError() { // ここではダミー実装なのでnullを返しているが、 // 必要な情報を格納したオブジェクトであるべき return null; } /** * {@inheritDoc} * @see java.lang.Thread#run() */ @Override public void run() { try { while (!this.isInterrupted()) { // ループ処理 // ... } // TODO 処理結果を格納 // 正常終了 this.status = Status.FINISHED; } catch (RuntimeException e) { // 異常終了 this.status = Status.ERROR; } } /** * ポーリングの反応がなくなった際に処理を停止させるためのTimerTask */ class Canceler extends TimerTask { /** * {@inheritDoc} * @see java.util.TimerTask#run() */ @Override public void run() { // 割り込み ThreadManager.this.interrupt(); } } }

ポイントとしてはループ処理の際、Thread#isInterrupted()を参照してループを回している点。このほか時間の掛かる処理の前後で中断できるように仕込みを入れておく必要があります。

そして、10秒後にThreadを停止するタイマーを起動しています。
このタイマーはポーリングによるアクセスでリセットされます。つまり、途中でユーザがブラウザを閉じるなどのキャンセルを行った場合に、重い処理を途中で停止させるための仕掛けです。

一方Servletの方では

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // Sessionから管理オブジェクトを取得 HttpSession session = request.getSession(); ThreadManager manager = (ThreadManager) session.getAttribute(MANAGER_KEY); // 管理オブジェクトがない場合は作成してSessionに格納 if (manager == null) { manager = new ThreadManager(); session.setAttribute(MANAGER_KEY, manager); } String dispatchUrl; switch (manager.getStatus()) { case READY: // Threadの開始 manager.start(); // ポーリング画面を表示 dispatchUrl = URL_POLLING; break; case RUNNIG: // Thread停止タイマをリセット manager.resetTimer(); // ポーリング画面を表示 dispatchUrl = URL_POLLING; break; case FINISHED: // 完了画面を表示 dispatchUrl = URL_FINISH; request.setAttribute(DATA_KEY, manager.getData()); break; case ERROR: // エラー画面を表示 dispatchUrl = URL_ERROR; request.setAttribute(ERROR_KEY, manager.getError()); break; default: throw new IllegalArgumentException(); } RequestDispatcher rd = request.getRequestDispatcher(dispatchUrl); rd.forward(request, response); }

初回に管理オブジェクトを作成し、Threadを起動。
2回目以降は停止タイマのリセットを行い、進捗表示画面を表示。完了、もしくはエラーだった場合はそれらの表示画面へと遷移させます。

注意点

適当にかいたソースなので同期をまじめに取っていません。 Sessionを触る際は同期を取る必要があります。2重にHTTPリクエストが飛んできた場合には併走するThreadからセッションをいじることになるためです。

ともかく、時間の掛かる処理などを裏で実行して完了時に結果を表示する場合は、こんな感じのつくりになります。

AOPトランザクション＋キャッシュの組み合わせは同期に気をつける

凪瀬 — Sat, 06 Oct 2007 15:08:00 GMT

先日遭遇した深い落とし穴を紹介します。以下のようなシステムを開発している方は同様の問題がないかチェックしてください。

AOPでトランザクションを管理している

一部のマスタテーブルをDBから読み込んだあとシステム内でキャッシュしている

マスタメンテナンス画面などで更新があった場合にキャッシュをクリアしている

問題となるコード

Springや、SeasarといったDIコンテナなどに付随するAOPの機能を用いてトランザクション管理していると、 DBをいじる部分のメソッド内ではcommitとかrollbackとか記述する必要がありません。これは非常に便利で、人的なコーディングでのcommit漏れ、rollback漏れがないのでバグも入り込みにくく効率のよいものです。

私のやっているプロジェクトではSpringframeworkのAOPの機能を用いてトランザクション管理を行っています。

そして、システム内でよく使われ、更新頻度の低いUserテーブルは、DBアクセスのオーバーヘッドを軽減するためにシステム内でキャッシュしているのです。

/** ユーザのキャッシュ */ Map<Integer, User> cache; /** ユーザ取得処理 */ public User getUser(int userId) { synchronized (this.cache) { // キャッシュにあればキャッシュされたUserを返す if (this.cache.containsKey(userId)) { return this.cache.get(userId); } // なければDBから読み込む return this.userDao.getUser(userId); } } /** キャッシュの削除処理 */ public void clearCache(int userId) { synchronized (this.cache) { this.cache.remove(userId); } }

キャッシュの実装は上記のようなもので、内部で同期をとってあります。
そして、UserのUPDATE処理では

public void update (User user) { // UPDATE this.userDao.update(user); // キャッシュから更新対象のUserを削除 // 次回Userを取得しようとした時にキャッシュに最新のUserが読み込まれる clearCache(user.getUserId()); }

といった作りにしていたのです。このupdateメソッドに対してAOPでトランザクションがかけられるわけですね。

Commit前、キャッシュクリア後の魔

前置きが長くなりました。問題が発生するのはこのupdateの際のキャッシュのクリアの後です。

並列して走っているスレッドがあり、update後のキャッシュクリア後、しかしDBのcommitが完了する前のタイミングで getUser()してしまったのです。
すると、DBはcommitされる前ですから、更新前のUser情報が読み込まれ、キャッシュには古い情報が残り続けるというわけ。

DBのトランザクションとキャッシュクリアは不可分に行わなければならないのです。
しかし、AOPでトランザクションを管理している場合、メソッド境界を跨ぐことになるので synchronized文で容易にくくってやることができない…。

わざわざキャッシュ管理している場所だけ特殊なトランザクション処理を別途書いてAOPを適用してやる必要が出てきてしまいました。
似たようなシステム構成をしている方、潜在的なバグを孕んでいる可能性があります。早急にチェックするほうがよいでしょう。

セッションを扱う際には同期を意識する

凪瀬 — Thu, 04 Oct 2007 13:53:00 GMT

J2EEでのWebアプリケーション開発では、簡素なルールを守りさえすればそれほど同期処理を考える必要はありません。

各クラスにstaticな可変のフィールドを作らない
Servletの実装クラスにインスタンスフィールドを作らない
セッションを用いない

概ね、上記を守っていれば複数のユーザが並列にHTTPリクエストを投げたところで同期に起因するバグは発生しない。 DBへのアクセスは当然ながらDB側でトランザクション管理されているものとします。

セッションには同期が必要

さて本題のセッションですが、こいつを使う場合、並列してHTTPリクエストが送られてきた場合を想定する必要があります。セッションは同一ユーザからのアクセスで同じものが参照できるわけですから、ユーザがブラウザから複数のHTTPリクエストを発すると複数のスレッドから同時にセッションが参照されることになります。

そうなると、スレッドを扱う際の問題と同じことがおきます。例えば以下のコード、セッションからキー"test"で値をとってきて、+1して格納しなおすだけですが、

HttpSession session = request.getSession(); Integer i = (Integer) session.getAttribute("test"); // (A) i = new Integer(i.intValue() + 1); // (B) session.setAttribute("test", i); // (C)

ふたつのリクエスト(以下ではR1、R2と呼びます)から、ソースのA、B、Cが

R1	R2
(A)
↓	(A)
(B)	↓
↓	(B)
(C)	↓
	(C)

というタイミングで動くと、元もとセッションに値"1"が格納されていたとしても、 2つのリクエストでそれぞれ+1されて"3"となると思いきや、"2"という値が格納されることになります。

R1の(A)で"1"を読み出し、R2の(A)でも"1"が読み出されるのです。そして、R1の(C)で"2"を書き込み、R2の(C)でも"2"を書き込む…。

上記は簡単な例ですが、セッションに格納した情報をいじるというのは実は大変難しいことなのです。

対策

対策としては並列処理のプログラミングの知恵をそのまま生かすことができます。

セッションからの読み出しから書き込みまでをsynchronizedキーワードによって同期する方法で防ぐことができます。しかし、同期すると同時にひとつの処理しかできないわけですから重たい処理をロックするとHTTPリクエストが大渋滞を起こしてしまうことがあります。リロードボタンでDoSアタックができてしまうようでは困りますね。

ロックを行わない同期としてはコンペア・アンド・スワップなどの手法があります。楽観排他などとイメージは似ていますね。書き込み段階で読み出した値と違っていないかを確認することで、途中で書き換えられていた場合にエラーで落とすことが出来ます。

この先はもう並列処理の話になってしまうので本稿では割愛しますが、セッションを扱う際には同期を意識する必要があることは心にとどめ置いてください。

サーバサイドJavaでのメモリ上限

凪瀬 — Thu, 20 Sep 2007 16:26:00 GMT

Programming SHOT BARへようこそ。本日はVMの管理するメモリの話です。メモリリークによるOutOfMemoryの話ではありません。

VMが扱えるメモリの上限

一般的な32bitのJavaVMが管理できるメモリの上限は1.7G程度です。 JavaのVM自体はOSから見れば単一アプリケーションにすぎません。 Javaのアプリケーション内でのメモリ確保は、VMが確保したメモリが分配されているわけです。ですから、OS上からJavaVMが確保しているメモリを見てもVM内でどれだけのメモリが利用されているかはわかりません。

これはわりと嵌る人が多いように思います。少なくとも過去にBBSで2度以上見た覚えがあります。 Javaでもメモリ使用量を観測しようとした場合、WindowsのタスクマネージャでJavaVMが使用しているメモリを見てもあまり意味がありません。これはVMが確保しているメモリ総量よりは大きい値になりますが、確保した領域中、どれだけが空きメモリなのかはわからないのです。それはOSの知るところではなく、JavaVMの管理下にある情報なのです。 JavaVM内での空きメモリは java.lang.Runtime#freeMemory()で参照できます。またjconsole によって外から接続してメモリ使用状況を確認することも出来ます。

JavaVMが確保するメモリの上限は実行時のオプションで設定できます。 javaコマンドのリファレンスで説明されていますが、オプション-Xmxで上限設定をすることができます。しかし、上限はVMの実装によるため、ここでは設定できる上限値についての情報は記述されていません。 VMの実装によっては2Gを超えるヒープ領域が扱える"Large Heap"と呼ばれる機能を備えているものもあるようです。

Javaアプリケーションの稼動するサーバを構築した場合、 JavaVM自体はVMの本体も含め2G程度のメモリしか消費しません。それを超える物理メモリを乗せていても活用できない場合があります。サーバサイドで動かすのであれば64bit版のVMを使いたいところです。

たとえ64bit版を使っていたとしても物理メモリを超える容量を設定してはいけません。 OSが仮想メモリをサポートしているでしょうから止まるということは無いにしても、深刻なパフォーマンスの劣化をもたらす場合があります。
VMは該当オブジェクトが配されているメモリがスワップされた領域なのか、そうでないのかを管理するわけではありませんから、多量のスワップが発生することがあります。

そのような事情から、Javaのアプリケーションで使用できるメモリの上限はおのずと制限されます。

上限を振り切る可能性

サーバサイドでの処理は時にヘビィで、瞬間的に大量のメモリを消耗することがあります。 Excelファイルを生成するApache POIなどはその典型で、非常に多くのメモリを消耗します。サーバサイドでは並列にユーザからリクエストを受けるのが通常ですから、このメモリを食う処理が多重に動いた場合、メモリ上限を超え、OutOfMemoryとなることがあります。

これはメモリリークではないため、抜本的な対応は難しいのですが、VM内で片付けるなら Worker Threadパターン( 増補改訂版 Java言語で学ぶデザインパターン入門マルチスレッド編の8章参照)を利用します。作業用のThread本数を制限し、同時に多量に並列起動しないようにするわけです。 JavaSE5.0以降であればjava.util.concurrent.ThreadPoolExecutorを使うことで比較的容易に対応できます。

しかし、いずれにせよデータ量で使用メモリが変動しますから、正確な上限がつかめるわけではありません。いっそ、POIによるExcel生成を別VMに分けてしまって、VM間で受け渡しするようなシステム構成を考えたほうがよいのではないでしょうか。

スレッドのキャンセル

凪瀬 — Tue, 28 Aug 2007 20:28:00 GMT

Programming SHOT BARへようこそ。ここのところマルチスレッド関連の話題で盛り上がっています。今日はかつのりさまからのリクエストでスレッドのキャンセルにまつわる話です。

参考資料

以下の書籍を参考にしています。手元にある方は参照してみてください。

プログラミング言語Java第4版 14.8.1 スレッドのキャンセル 318p
Java並行処理プログラミング 7-1 タスクのキャンセル 154p
増補改訂版 Java言語で学ぶデザインパターン入門マルチスレッド編補講1 例外InterruptedExceptionを理解する 179p
Javaスレッド完全制覇 4.2 割り込み 102p

Thread#stop()とその問題点

Thread#stop()、Thread#suspend()、Thread#resume()という一連のスレッドの停止・再開メソッドは 非推奨メソッドなっており、使用してはいけません。
この件については、sunからわざわざ詳細な説明がアナウンスされています。 http://java.sun.com/j2se/1.5.0/ja/docs/ja/guide/misc/threadPrimitiveDeprecation.html

スレッドは外部から強制的に、しかし、安全に停止させることはできません。なんらかの処理をしている最中に安全に中断するということは本質的に難しいのです。
その状況によって後始末を必要とします。停止の要求に対して、「ちょっとまって。今中断するから」といった協力なしには安全な停止はなしえません。

フラグを立ててスレッドを停止させる

スレッドに対し、割り込みフラグを用意することで自発的な停止をさせることが出来ます。

/** 割り込みフラグ */ private volatile boolean stopFlag; @Override public void run() { while(!this.stopFlag) { // 実処理 } }

上記サンプルではvolatileによってメモリ同期化されたフラグを利用して、 whileループを抜けるようにしてあります。このように、外部からフラグを変更してやることでスレッドを自発的に停止させています。

しかし、Object#wait()やObject#join()などのスレッドをブロックするメソッドを利用している場合、フラグを判定する箇所（キャンセルポイントといいます）まで永遠にたどり着くことはないかもしれません。

個々のプログラマが独自に定義したスレッドの割り込みフラグの限界はここにあります。 APIのような不特定多数に利用してもらう場合には、やはり標準的な仕組みが欲しいですね。

Thread#interrupt()はその標準的なスレッドの割り込みフラグなのです。

Thread#interrupt()

Thread#interrupt()はThread標準で提供される停止フラグの通知機構です。この呼び出しで対象のスレッドに対して割り込みフラグが立ちます。
この割り込みフラグはThread#isInterrupt()によって参照することができます。 staticなメソッドThread#interrupted()を使うと、現在のスレッドの割り込みフラグを参照した上でフラグをリセットすることが出来ます。詳しくはjavadocを参照してください。

Object#wait()はThread#interrupt()によってスレッドの停止フラグが立つと、 waitすることを止めて、InterruptedExceptionをthrowします。
waitに限らず、ブロックされるメソッドは、基本的にスレッド停止フラグが立つと InterruptedExceptionをthrowする作りになっています。

また、先のサンプルのように、ブロックされないスレッドにおいては、Thread#interrupt()を利用しなくてもスレッドの停止を行うことが出来ます。

では、我々プログラマが独自に作成したスレッドではこのどのような対処をする必要があるのでしょうか？

InterruptedExceptionをthrowするように作る
Thread#interrupt()で立てられた割り込みフラグを維持し、どこかのキャンセルポイントまで流す
自力でキャンセル処理をし、スレッドを終了させる

という３つの選択肢があります。スレッドから呼び出される想定のメソッドで、処理が長引くことが想定される場合は InterruptedExceptionをthrowする作りにしておくとよいでしょう。例えば集計処理などの時間が掛かる処理ですね。
そもそも、そんなに時間の掛からない処理であれば、キャンセルポイントを作る必要もありません。フラグに触らずそのまま処理を終えてどこかのキャンセルポイントにお任せします。
Thread#run()のような場所ではExceptionをthrowsするように宣言できませんから、こういう箇所では自力でキャンセルポイントを実装してやります。

あらかじめThread#interrupt()による割り込みをチェックして中断させるキャンセルポイントを作っておくことで、無駄な処理を続けることなく速やかに停止させることが出来ます。せっかちな現代人には必須の機能かもしれませんね。

業務での応用

集計処理など時間が掛かることが想定されるメソッドは、Thread#interrupt()による停止をサポートしておくと、途中キャンセルされた場合に処理を止めることで CPUリソースを無駄に食わずに済みます。

java.nio.channels.InterruptibleChannelによる通信であれば、通信に割り込んで停止させることも可能です。

このあたり、業務要件で顧客から直接要望されることは少ないでしょうが、パフォーマンスにこだわりがあるお客さん相手なら、設計段階から中断についても考慮しておくと良いかもしれません。

スレッドから値を返すには - その２

凪瀬 — Mon, 27 Aug 2007 21:12:00 GMT

前回から別の方向に大きく逸れてしまいましたが、別スレッドでの結果を取得する第２回です。

下記コードはThread.join()を使って他のスレッドの終わりを待って値を取得しようというサンプルです。

/** * joinを用いて他のThreadの結果を取得するサンプル。 * 同期が行われていないので潜在的な危険を孕んでいる？ */ public class JoinTest extends Thread { /** return用の値 */ private int value; /** Threadでの処理 */ @Override public void run() { // 実処理 // ... this.value = 0; } /** * 値取得用のメソッド。 */ public int getValue() { return this.value; } public static void main(String[] args) throws Exception { JoinTest t = new JoinTest(); t.start(); // Threadの終了を待つ t.join(); // 結果の取得 int ret = t.getValue(); } }

私の理解が正しければ、このコードは正しい値を返さない可能性があるのではないでしょうか？

double-checked locking問題と同じ？

どうにもこのコード、 double-checked locking問題と同じ匂いがするのです。

Thread.join()による待機の完了は、対象スレッドのどの処理よりも後となることは保証されています。では、上記サンプルのように対象スレッド内でフィールドに書き出しておいて、 join()で終わりを待って値を読み込めば正しく値が読み出せるように思えます。

ところが、Thread.join()は同期されるわけではないので、この時点でメモリが同期されていることを期待してはいけないのではないでしょうか？

受け渡し用のフィールドがvolatileでありさえすれば、問題は起こらないことでしょう。しかし非volatileでかつ非synchronizedの場合は…？

クラス設計上の問題

wait()方式に比べた弱点は、クラスとして完結させにくい点です。

少なくとも、Thread#start()の後にThread#join()して、それから値を取得してくださいね、なんて約束をクラスの利用者に守ってもらうというのは防衛的ではないですよね。

防衛的なクラス設計にするのであれば、getValue()メソッドの内部で完了を待機したいところです。そうなると、Thread#join()を実行するために、自身が実行されているThreadのインスタンスが必要となります。結局、Thread.start()までをもクラス内部に抱え込まないと安全で利便性の高いクラスにはできません…。

このように、クラス設計において、wait()方式に比べると若干面倒が多いように思えます。
InterruptedExceptionへの対応が必要な点や、同期が必要な点はwait()と変わりませんからメリットは特に無いのではないでしょうか。Threadはリソースも多く食いますしね。

double-checked-locking問題のまとめ

凪瀬 — Fri, 24 Aug 2007 09:52:00 GMT

先のエントリでもりあがったdouble-checked-locking問題についてのまとめです。

参考資料

IBMの記事が質が高くて分かりやすいですね。

double-checked lockingとSingletonパターン(2002年5月)
Javaの理論と実戦: Javaメモリ・モデルを修正する　第1回(2004年2月24日)
Javaの理論と実戦: Javaメモリ・モデルを修正する　第2回(2004年3月30日)
コンパイラ開発者のためのJSR133クックブック

double-checked locking問題とは

「double-checked lockingとSingletonパターン」では、GoFデザインパターンのSingletonパターンを Javaで実装する際に同期の処理コストも含め、どのようにすべきかについて書かれています。

「double-checked locking」と呼ばれるアルゴリズムは、下記のようなコードです。

public class Singleton { private static Singleton instance; public static Singleton getInstance() { if (instance == null) { synchronized(Singleton.class) { if (instance == null) instance = new Singleton(); } } return instance; } }

このコードは、同期による処理コストも少なく、かつ正しく同期され、Singletonが実装されているように見えます。

しかし、思いもよらない問題が顔を出します。 このgetInstance()返されるインスタンスはnullではないにも関わらず、コンストラクタによる初期化が終わっていない可能性がある、という話です。

べつに同期自体がうまくいかず、複数回インスタンスが生成されるというわけではありません。メモリを確保し、参照が作られ、その後にコンストラクタが動く、その流れのなかで、コンストラクタが動く前に参照がreturnされることがある、ということをIBMの記事では解説しています。

先のエントリのコメントでは、この参照は作られたが初期化がされていないタイミングを逢魔が刻とたとえたのでした。

これは、最適化などのために処理が変わらない範囲での順序の変更が許されているという VM実装の事情によるもののようです。これがメモリの同期と絡まって出てきた逢魔が刻こそが double-checked locking問題ということになります。

JSR 133

Javaの仕様はJCP(Java Community Process)という機関で決められます。
ここで議論される要求がJSR(Java Specification Reqest)です。このあたりのプロセスは Javaの開発者は，ちょっと“うるさい” という記事が分かりやすいかと思います。

JSR 133はJavaのメモリモデルに対する仕様変更要求です。「コンパイラ開発者のためのJSR133クックブック」がこのJSR 133について詳しく解説しています。今回参考資料に挙げたリンクは原文と日本語との対訳で書かれているので読みやすいと思います。

このJSR 133はJavaSE 5.0から搭載されています。

問題は解決するのか？

JSR 133によって、volatileなフィールドに関しては、参照は作られたが初期化がされていない逢魔が刻は存在しないようです。
この点についてはIBMの記事に解説があるので、ちょっと長いですが引用します。

これはdouble-checked locking問題を解決するのか？

double-checked locking問題に対して提案されている解決方法の一つは遅延初期化されたインスタンス（lazily initialized instance）を保持するフィールドをvolatileフィールドにするというものです。（double-checked locking問題と、その解決方法として提案されたアルゴリズム的な方法ではなぜうまく行かないかの説明については参考文献を見てください。）古いメモリ・モデルの下では、これではdouble-checked lockingをスレッド・セーフにしませんでした。その理由はvolatileフィールドへの書き込みは、他の非volatileフィールド（例えば新しくコンストラクトされたオブジェクトのフィールドなど）への書き込みで、やはりリオーダーでき、そのためvolatileインスタンス参照は、不完全にコンストラクトされたオブジェクトへの参照をやはり保持できたためです。

新しいメモリ・モデルの下では、double-checked lockingに対するこの「解決方法」で表現法（idiom）がスレッド・セーフになるのです。それにもかかわらず、まだこの表現法を使うべきではないのです！ Double-checked lockingの要点は、ごく初期のJDKでは同期化が比較的高価だったという大きな理由から、共通コード・パスの同期化を不要にするために考えられた、パフォーマンス最適化のはずだった、ということなのです。その後、非競合同期化（uncontended synchronization）はずっと安価になったのですが、volatileの意味体系に加えられた新しい変更によって、一部のプラットフォームでは古い意味体系よりも比較的高価になってしまったのです。（実質的には、volatileフィールドへの各読み書きはちょうど、「半」同期化のようなものです。つまりvolatileの読み込みはモニターが取得するのと同じメモリ意味体系を持ち、volatileへの書き込みはモニターが解放するのと同じ意味体系を持っているのです。）ですから、double-checked lockingの目標が、より単純な、同期化による手法よりも改善されたパフォーマンスを得る事だとすると、この「修正版」解決方法もあまり役には立たちません。

このように、volatileである場合はスレッドセーフになりうると書かれています。
ではなぜ、単なるdouble-checked lockingでは駄目なのでしょう？メモリモデルが変更になったのだから、synchronizedでちゃんと同期してくれるようになったんじゃないの？
私の理解では、volatileでもsynchronizedでも、メモリの同期は行われるわけですが、 volatileフィールドへの代入に際しては最適化のための順序置き換えが禁止されるため、逢魔が刻を回避できる、単なるsynchronizedによるメモリ同期ではそれを回避できない、という解釈です。
このあたりの結論は自信がないので、是非、コメントで突っ込みを入れてください。

結論

結局のところ、JavaSE 5.0だとしても、冒頭に掲げたサンプルコードでは初期化されていない参照が返される可能性があるということになるのではないでしょうか。

volatileフィールドを利用することで回避することはできるのでしょうが、同期のコストを回避するというdouble-checked lockingの本来の目的は達成できない、という結論となるようです。

waitについてのまとめ

凪瀬 — Wed, 22 Aug 2007 11:46:00 GMT

並列処理でえらく盛り上がってしまったので一旦まとめたいと思います。
こちらのエントリではObject#wait()についてのまとめです。

waitの使い方

Object#wait()を呼び出すことで現在のThreadを停止させることが出来ますが、この際のObjectのインスタンスは Javaの並列処理の基本の稿で説明したロックオブジェクトを用います。

wait()を呼び出す前に、対象となるオブジェクトをロックオブジェクトとして synchronizedブロックを作らねばなりません。

Object lock = new Object(); // ロックオブジェクトでsynchronizedブロックを作る synchronized (lock) { // ロックオブジェクトのwait()を呼び出す lock.wait(); }

synchronizedブロックの外でwait()を呼んだ場合は IllegalMonitorStateExceptionがthrowされます。

Object#notify()およびObject#notifyAll()でwait()しているスレッドは動き出します。このnotifyのインスタンスはもちろん、waitするときに利用したロックオブジェクトです。
notify()もまた、自身をロックオブジェクトとしたsynchronizedブロック内で呼び出さないとIllegalMonitorStateExceptionをthrowします。
ロックオブジェクトをうまく管理すれば、停止再開を行う箇所をグルーピングできるわけです。

spurious wakeup

スプリアス・ウェイクアップと呼ばれる現象が知られています。本来起きるべきではないタイミングでwait()から目覚めることがある、という現象です。

この現象については Object#wait()のjavadocにも記載があります。

スレッドは、通知、割り込み、タイムアウトなしに再開されることがあります。これは、「スプリアスウェイクアップ」と呼ばれています。スプリアスウェイクアップは、実際にはまれにしか発生しませんが、アプリケーションでは、スレッドが再開されることで発生する可能性がある条件をテストし、条件が満たされない場合は待機を続けて、スプリアスウェイクアップから保護しなければなりません。つまり、次のようにループで常に待機が発生するようにする必要があります。

synchronized (obj) {
while ()
obj.wait(timeout);
... // Perform action appropriate to condition
}

(このトピックの詳細は、Doug Lea 著『Concurrent Programming in Java (Second Edition)』(Addison-Wesley, 2000) のセクション 3.2.3 や Joshua Bloch 著『Effective Java Programming Language Guide』(Addison-Wesley, 2001) のアイテム 50 を参照してください)。

ここで引き合いに出されているEffective Javaでは

待ちスレッドは、通知がなくても起きるかもしれません。これは、偽りの目覚め(sputious wakeup)と呼ばれます。『Java 言語仕様』[JLS]がその可能性について述べていないにもかかわらず、多くのJVM実装は、たとえ稀であるにせよ、偽りの目覚めが起きることが知られているスレッド機構を使用しています[Posix, 11.4.3.6.1]。

と記述されています。([]の記述は参考文献)

実際、Java言語仕様(日本語版訳第3版)の 506ページ、「17.8待機集合と通知」にはスプリアス・ウェイクアップの記述はありません。

また、Java並行処理プログラミングでも 337ページ、「14-2-2 早すぎるウェイト終了」にて紹介されています。（yamasaさま、情報ありがとうございます）

我々が気をつけなければならないこと

正に問題となるのは以下のようなコードです。

synchronized (this.lock) { // 終了前ならwait if (!this.flag) { this.lock.wait(); } // 値を返す return this.value; }

フラグが立っていなければwaitし、どこか別のスレッドでこのフラグが立てられ、 notifyされて動き出すことを期待しています。

しかし、ここで前述のスプリアス・ウェイクアップが起きるとしたら、まだthis.flagがfalseのうちに動き出し、値をreturnしてしまう可能性があるのです！

そのため、以下のようにwhileループを用いて不意に動き出したときの対策をしなければなりません。

synchronized (this.lock) { // 終了前ならwait while (!this.flag) { this.lock.wait(); } // 値を返す return this.value; }

javadocに記載されたミステリー

Object#wait()は３つのオーバーロードを持っていますが、引数なしのオーバーロードには以下の記述があります。

引数が 1 つのバージョンでは、割り込みやスプリアスウェイクアップが発生する可能性があるので、このメソッドは常にループで使用される必要があります。

引数なしのwait()ではスプリアス・ウェイクアップが起きないかのような記述です。
日本語訳の誤りかと思ったのですが、

As in the one argument version, interrupts and spurious wakeups are possible, and this method should always be used in a loop:

英語版の記述が上記通りなので、翻訳の誤りではないようです。
このあたりはEffective Javaの言うところの「偽りの目覚めが起きることが知られているスレッド機構」とやらを調べて見ないと結論できないように思います。