ダブル・チェック・ロッキング - 版の履歴

Administrator: /* C# */

2023-05-19T05:08:46Z

← 古い版		2023年5月19日 (金) 05:08時点における版
26行目:		26行目:
	public static MySingleton GetInstance()		public static MySingleton GetInstance()
	{		{
	// ~~1回目のチェック~~		// 1回目の大雑把なチェック
	// ~~ロックしていないので高速に処理される~~		// ロックしていない「nullではない場合」の処理が高速化されます。
	if (null == _instance)		if (null == _instance)
	{		{
	// ロック		// ロック
	// ~~※このブロック内はクソ重い~~		// ここで処理は急激に重くなります。
	lock (_sync)		lock (_sync)
	{		{
	// ~~2回目のチェック~~		// 2回目の厳密なチェック
	if (null == _instance)		if (null == _instance)
	{		{

2022年4月18日 (月) 02:27にAdministratorによる

2022-04-18T02:27:42Z

← 古い版		2022年4月18日 (月) 02:27時点における版
1行目:		1行目:
	'''ダブル・チェック・ロッキング'''（[[英語]]：double check locking）とは、[[マルチスレッド]]環境下における[[変数]]に対して、初回は[[ロック]]~~せず状態チェックを行い、そこで必要であれば再度~~[[ロック]]~~を掛けた後に状態チェックを行うという~~[[ソフトウェア]]の[[最適化]]技法、[[デザインパターン]]のひとつである。		'''ダブル・チェック・ロッキング'''（[[英語]]：double check locking）とは、[[マルチスレッド]]環境下における[[変数]]に対して、初回は[[ロック]]せず大雑把に状態チェックを行い、そこで必要であれば再度[[ロック]]を掛けた後に厳密に状態チェックを行うという[[ソフトウェア]]の[[最適化]]技法、[[デザインパターン]]のひとつである。

	==概要==		==概要==
	ダブル・チェック・ロッキングは、主に[[マルチスレッド]]環境下での[[シングルトンパターン]]を実装する際に[[オーバーヘッド]]の低減を目的として使われることが多い。		ダブル・チェック・ロッキングは、主に[[マルチスレッド]]環境下での[[シングルトンパターン]]を実装する際に[[オーバーヘッド]]の低減を目的として使われることが多い。

	マルチスレッド下における[[変数]]の[[ロック]]は非常に[[オーバーヘッド]]が大きくスレッド数に比例して重くなる。ダブル・チェック・ロッキングはそのような状況下でロックの発生回数を可能な限り減らすことで[[プログラム]]~~の高速化を実現しようというものである。なお、シビアな速度を要求されないのであれば~~[[ソースコード]]としては何も考えず常にロックした方が簡潔明瞭ではある。		マルチスレッド下における[[変数]]の[[ロック]]は非常に[[オーバーヘッド]]が大きくスレッド数に比例して重くなる。ダブル・チェック・ロッキングはそのような状況下でロックの発生回数を可能な限り減らすことで[[プログラム]]の高速化を実現しようというものである。

			なお、シビアな速度を要求されないのであれば[[ソースコード]]の[[可読性]]としては何も考えず常にロックした方が簡潔明瞭ではある。

	== 主なプログラミング言語での実装例 ==		== 主なプログラミング言語での実装例 ==

103.22.200.102: /* Java */

2017-05-01T01:14:28Z

Java

← 古い版		2017年5月1日 (月) 01:14時点における版
77行目:		77行目:

	=== Java ===		=== Java ===
	[[Java]]では[[仕様]]において[[アウトオブオーダー]]を用いるメモリモデルが可能となっていたため、この[[イディオム]]を使うことには問題があり、一部の[[実装]]では実際に正しく働かない可能性があることが知られている。詳細は http://www.ibm.com/developerworks/jp/java/library/j-dcl/ ~~を参照。~~		[[Java]]では[[仕様]]において[[アウトオブオーダー]]を用いるメモリモデルが可能となっていたため、この[[イディオム]]を使うことには問題があり、一部の[[実装]]では実際に正しく働かない可能性があることが知られている。詳細は http://www.ibm.com/developerworks/jp/java/library/j-dcl/ を参照。大雑把にいえばJavaでは「new（メモリ確保）」と「コンストラクタ実行」のタイミングが異なる。

	[[Java]]では絶対にダブルチェックロッキングを使用してはならない。		よって、[[Java]]では絶対にダブルチェックロッキングを使用してはならない。

	たとえば以下のような[[Java]]の[[ソースコード]]があったとする。		たとえば以下のような[[Java]]の[[ソースコード]]があったとする。
89行目:		89行目:
	# １行目で[[メモリ]]が確保される。		# １行目で[[メモリ]]が確保される。
	#: いわゆるmallocが実行されhage[[変数]]自体は[[null]]ではなくなる。		#: いわゆるmallocが実行されhage[[変数]]自体は[[null]]ではなくなる。
	#: ただし[[コンストラクタ]]~~はまだ実行されない。~~		#: ただし[[コンストラクタ]]はまだ実行されていない。
	# ~~2行目の初めて使うときにコンストラクタが実行される。~~		# 2行目のインスタンスを初めて使うときにコンストラクタが実行される。
	#: [[コンストラクタ]]が実行されるタイミングは、オリジナル（newを実行した[[スレッド]]の持つ）インスタンスに対して外部から[[メンバー関数]]や[[メンバー変数]]に初回アクセスがあったときとなる。これを[[遅延初期化]]（lazy initialization）という。これによりhage[[変数]]自体は[[null]]ではないので後続スレッドはコンストラクタを実行していない不完全な[[インスタンス]]の[[参照]]を取得できてしまう。		#: [[コンストラクタ]]が実行されるタイミングは、オリジナル（newを実行した[[スレッド]]の持つ）インスタンスに対して外部から[[メンバー関数]]や[[メンバー変数]]に初回アクセスがあったときとなる。これを[[遅延初期化]]（lazy initialization）という。これによりhage[[変数]]自体は[[null]]ではないので後続スレッドはコンストラクタを実行していない不完全な[[インスタンス]]の[[参照]]を取得できてしまう。

2015年12月10日 (木) 01:12にimported>Administratorによる

2015-12-10T01:12:24Z

← 古い版		2015年12月10日 (木) 01:12時点における版
1行目:		1行目:
	'''ダブル・チェック・ロッキング'''（[[英語]]：double check ~~locking）とは、マルチスレッド環境下における~~[[変数]]に対して、初回は[[ロック]]せず状態チェックを行い、そこで必要であれば再度[[ロック]]~~を掛けたのちに状態チェックを行うという~~[[ソフトウェア]]の[[最適化]]技法、[[デザインパターン]]のひとつである。		'''ダブル・チェック・ロッキング'''（[[英語]]：double check locking）とは、[[マルチスレッド]]環境下における[[変数]]に対して、初回は[[ロック]]せず状態チェックを行い、そこで必要であれば再度[[ロック]]を掛けた後に状態チェックを行うという[[ソフトウェア]]の[[最適化]]技法、[[デザインパターン]]のひとつである。

	[[変数]]の[[~~ロック~~]]~~は非常に~~[[オーバーヘッド]]~~の大きい重たい処理であるため、その発生回数を可能な限り減らすことで[[プログラム]]の高速化を実現しようというものである。~~		==概要==
			ダブル・チェック・ロッキングは、主に[[マルチスレッド]]環境下での[[シングルトンパターン]]を実装する際に[[オーバーヘッド]]の低減を目的として使われることが多い。

	~~ダブル・チェック・ロッキングは、主に~~[[~~マルチスレッド~~]]~~環境下での~~[[~~シングルトンパターン~~]]~~を実装する際に~~[[オーバーヘッド]]~~の低減を目的として使われることが多い。~~		マルチスレッド下における[[変数]]の[[ロック]]は非常に[[オーバーヘッド]]が大きくスレッド数に比例して重くなる。ダブル・チェック・ロッキングはそのような状況下でロックの発生回数を可能な限り減らすことで[[プログラム]]の高速化を実現しようというものである。なお、シビアな速度を要求されないのであれば[[ソースコード]]としては何も考えず常にロックした方が簡潔明瞭ではある。

	== 主なプログラミング言語での実装例 ==		== 主なプログラミング言語での実装例 ==
44行目:		45行目:

	=== C# (Lazy) ===		=== C# (Lazy) ===
	[[.NET Framework 4.0]]~~では、標準でLazy~~<T>~~クラスが用意されており、それを使うことでよりシンプルにダブル・チェック・ロッキングを記述できるようになった~~<!--<ref>{{cite		[[.NET Framework 4.0]]から標準でLazy<T>クラス（System名前空間）が用意されており、これを使うことで簡潔明瞭にダブル・チェック・ロッキングを記述できるようになった<!--<ref>{{cite
	\|title=C# 4.0 in a Nutshell		\|title=C# 4.0 in a Nutshell
	\|last=Albahari		\|last=Albahari

2015年12月10日 (木) 00:54にimported>Administratorによる

2015-12-10T00:54:53Z

← 古い版		2015年12月10日 (木) 00:54時点における版
1行目:		1行目:
	'''ダブル・チェック・ロッキング'''（[[英語]]~~：Double Check Locking）とは、マルチスレッド環境下における~~[[変数]]に対して、初回は[[ロック]]せず状態チェックを行い、そこで必要であれば再度[[ロック]]を掛けたのちに状態チェックを行うという[[ソフトウェア]]の[[最適化]]技法、[[デザインパターン]]のひとつである。		'''ダブル・チェック・ロッキング'''（[[英語]]：double check locking）とは、マルチスレッド環境下における[[変数]]に対して、初回は[[ロック]]せず状態チェックを行い、そこで必要であれば再度[[ロック]]を掛けたのちに状態チェックを行うという[[ソフトウェア]]の[[最適化]]技法、[[デザインパターン]]のひとつである。

	[[変数]]の[[ロック]]は非常に[[オーバーヘッド]]の大きい重たい処理であるため、その発生回数を可能な限り減らすことで[[プログラム]]の高速化を実現しようというものである。		[[変数]]の[[ロック]]は非常に[[オーバーヘッド]]の大きい重たい処理であるため、その発生回数を可能な限り減らすことで[[プログラム]]の高速化を実現しようというものである。

imported>Administrator: /* Java */

2015-12-10T00:53:33Z

Java

← 古い版		2015年12月10日 (木) 00:53時点における版
91行目:		91行目:
	# 2行目の初めて使うときにコンストラクタが実行される。		# 2行目の初めて使うときにコンストラクタが実行される。
	#: [[コンストラクタ]]が実行されるタイミングは、オリジナル（newを実行した[[スレッド]]の持つ）インスタンスに対して外部から[[メンバー関数]]や[[メンバー変数]]に初回アクセスがあったときとなる。これを[[遅延初期化]]（lazy initialization）という。これによりhage[[変数]]自体は[[null]]ではないので後続スレッドはコンストラクタを実行していない不完全な[[インスタンス]]の[[参照]]を取得できてしまう。		#: [[コンストラクタ]]が実行されるタイミングは、オリジナル（newを実行した[[スレッド]]の持つ）インスタンスに対して外部から[[メンバー関数]]や[[メンバー変数]]に初回アクセスがあったときとなる。これを[[遅延初期化]]（lazy initialization）という。これによりhage[[変数]]自体は[[null]]ではないので後続スレッドはコンストラクタを実行していない不完全な[[インスタンス]]の[[参照]]を取得できてしまう。

			[[Objective-C]]のallocとinitの動作に近いものが全自動で実行されてしまうような感じである。
			<source lang="objc">
			Parson* hage = [[Parson alloc] init];
			</source>

	<source lang="java">		<source lang="java">

imported>Administrator: /* Java */

2015-12-10T00:45:54Z

Java

← 古い版		2015年12月10日 (木) 00:45時点における版
83行目:		83行目:
	<source lang="java">		<source lang="java">
	Person hage = new Person();		Person hage = new Person();
			hage.say();
	</source>		</source>
	これが一部のJava実装では以下のような動作になる。		これが一部のJava実装では以下のような動作になる。
	# [[メモリ]]~~上に[[インスタンス]]が確保さる。~~		# １行目で[[メモリ]]が確保される。
	#: ~~hage~~[[変数]]自体は[[null]]ではなくなる。		#: いわゆるmallocが実行されhage[[変数]]自体は[[null]]ではなくなる。
	# [[コンストラクタ]]~~は実行されない。~~		#: ただし[[コンストラクタ]]はまだ実行されない。
	#: [[コンストラクタ]]が実行されるタイミングは、オリジナル（newを実行した[[スレッド]]の持つ）インスタンスに対して外部から[[メンバー関数]]や[[メンバー変数]]~~に初回アクセスがあったとき。これを~~[[遅延初期化]]（lazy initialization）という。これによりhage[[変数]]自体は[[null]]ではないので後続スレッドはコンストラクタを実行していない不完全な[[インスタンス]]の[[参照]]を取得できてしまう。		# 2行目の初めて使うときにコンストラクタが実行される。
			#: [[コンストラクタ]]が実行されるタイミングは、オリジナル（newを実行した[[スレッド]]の持つ）インスタンスに対して外部から[[メンバー関数]]や[[メンバー変数]]に初回アクセスがあったときとなる。これを[[遅延初期化]]（lazy initialization）という。これによりhage[[変数]]自体は[[null]]ではないので後続スレッドはコンストラクタを実行していない不完全な[[インスタンス]]の[[参照]]を取得できてしまう。

	<source lang="java">		<source lang="java">

2014年10月26日 (日) 01:29に126.212.131.37による

2014-10-26T01:29:17Z

← 古い版		2014年10月26日 (日) 01:29時点における版
1行目:		1行目:
	'''ダブル・チェック・ロッキング'''~~（英語：Double~~ Check ~~Locking）とは、初回は~~[[ロック]]~~なしで状態チェックを行い、そこで必要であれば再度~~[[ロック]]を掛けたのちに状態チェックを行うという[[ソフトウェア]]の[[最適化]]技法、[[デザインパターン]]のひとつである。		'''ダブル・チェック・ロッキング'''（[[英語]]：Double Check Locking）とは、マルチスレッド環境下における[[変数]]に対して、初回は[[ロック]]せず状態チェックを行い、そこで必要であれば再度[[ロック]]を掛けたのちに状態チェックを行うという[[ソフトウェア]]の[[最適化]]技法、[[デザインパターン]]のひとつである。

	[[ロック]]は非常に[[オーバーヘッド]]~~の大きい重い処理であるため、その発生回数を可能な限り減らすことで高速化を実現しようというものである。~~		[[変数]]の[[ロック]]は非常に[[オーバーヘッド]]の大きい重たい処理であるため、その発生回数を可能な限り減らすことで[[プログラム]]の高速化を実現しようというものである。

	ダブル・チェック・ロッキングは、主に[[マルチスレッド]]環境下での[[シングルトンパターン]]を実装する際に[[オーバーヘッド]]の低減を目的として使われることが多い。		ダブル・チェック・ロッキングは、主に[[マルチスレッド]]環境下での[[シングルトンパターン]]を実装する際に[[オーバーヘッド]]の低減を目的として使われることが多い。
76行目:		76行目:

	=== Java ===		=== Java ===
	[[Java]]~~では仕様において~~[[アウトオブオーダー]]を用いるメモリモデルが可能となっていたため、この[[イディオム]]~~を使うことには問題があり、一部の実装では実際に正しく働かない可能性があることが知られている。詳細は~~ http://www.ibm.com/developerworks/jp/java/library/j-dcl/ を参照。		[[Java]]では[[仕様]]において[[アウトオブオーダー]]を用いるメモリモデルが可能となっていたため、この[[イディオム]]を使うことには問題があり、一部の[[実装]]では実際に正しく働かない可能性があることが知られている。詳細は http://www.ibm.com/developerworks/jp/java/library/j-dcl/ を参照。


	[[Java]]では絶対にダブルチェックロッキングを使用してはならない。		[[Java]]では絶対にダブルチェックロッキングを使用してはならない。


	たとえば以下のような[[Java]]の[[ソースコード]]があったとする。		たとえば以下のような[[Java]]の[[ソースコード]]があったとする。
123行目:		121行目:
	== 参考文献 ==		== 参考文献 ==
	{{reflist}}		{{reflist}}

	~~== 外部リンク ==~~


	{{stub}}		{{stub}}

imported>GamerBook: /* Java */

2012-12-07T13:11:40Z

Java

← 古い版		2012年12月7日 (金) 13:11時点における版
77行目:		77行目:
	=== Java ===		=== Java ===
	[[Java]]では仕様において[[アウトオブオーダー]]を用いるメモリモデルが可能となっていたため、この[[イディオム]]を使うことには問題があり、一部の実装では実際に正しく働かない可能性があることが知られている。詳細は http://www.ibm.com/developerworks/jp/java/library/j-dcl/ を参照。		[[Java]]では仕様において[[アウトオブオーダー]]を用いるメモリモデルが可能となっていたため、この[[イディオム]]を使うことには問題があり、一部の実装では実際に正しく働かない可能性があることが知られている。詳細は http://www.ibm.com/developerworks/jp/java/library/j-dcl/ を参照。


			[[Java]]では絶対にダブルチェックロッキングを使用してはならない。

imported>GamerBook: /* Java */

2012-12-07T13:10:32Z

Java

@@ 76行目: / 76行目: @@
 === Java ===
-[[Java]]では仕様において[[アウトオブオーダー]]を用いるメモリモデルが可能となっていたため、この[[イディオム]]を使うことには問題があり、一部の実装では実際に正しく働かない可能性があることが知られている。 http://www.ibm.com/developerworks/jp/java/library/j-dcl/ を参照。
+[[Java]]では仕様において[[アウトオブオーダー]]を用いるメモリモデルが可能となっていたため、この[[イディオム]]を使うことには問題があり、一部の実装では実際に正しく働かない可能性があることが知られている。詳細は http://www.ibm.com/developerworks/jp/java/library/j-dcl/ を参照。
 == 関連項目 ==