シングルトンパターンの遅延初期化をスレッドセーフにするには - じゅんいち☆かとうの技術日誌
前回、前々回と割とヘビーな仕様の話だったので、今回は若干実用的なネタとして、シングルトンパターンの遅延初期化をメモリモデルの視点から、どのようにすればスレッドセーフになるか考えてみたいと思います。 そのシングルトンの遅延初期化はスレッドセーフか 以下のようなシングルトンパターンは日常的に使うデザインパターンの一つだと思います。 ただ、今回はSingletonクラスのgetInstanceメソッドに、わざとロックを掛けずに実装してみました。この場合にどういうことが起こりうるか考えてみたいと思います。 public class Singleton { private static Singleton instance; public static Singleton getInstance() { // バリアがない if (instance == null) { // Normal Load
生成だけではなく複製もファクトリに任せたほうがよい - かとじゅんの技術日誌
DDDで設計を始めると不変条件を維持するために、エンティティなどの可変オブジェクトの複製を行うことがよくあります。 Javaの場合は、Cloneableインターフェイスを実装して、実装型に応じた複製インスタンスを返すcloneメソッドを作る。以下のような感じ。 public class Employee implements Cloneable { private String name; // setter, getter 省略 @Override public Employee clone() { try{ return (Employee)super.clone(); } catch (CloneNotSupportedException e){ throw new Error(e); } } } このcloneメソッドは便利なので普通に使っていたのですが、最近、簡単に使ってよいのだ
マルチコア時代に備えて本気でメモリモデルを理解しておこう - メモリバリア編 - - じゅんいち☆かとうの技術日誌
このエントリを読む前提条件として、マルチコア時代に備えて本気でメモリモデルを理解しておこう - リオーダー & finalフィールド 編 - - じゅんいち☆かとうの技術日誌を読んで、リオーダーとは何かを理解していることとします。 前回のおさらいをすると、 プログラムの実行順序は、リオーダーが許可される場合と禁止される場合がある。並行処理ではリオーダーを想定しなければ、処理結果の整合性が確保できない。(特にマルチプロセッサ環境) リオーダーを禁止して、可視性を保証する。(finalフィールドはコンストラクト時に完全に初期化され、コンストラクト後はスレッドから見えるようになる) でした。 リオーダーについて理解できたら、今度はメモリバリア命令でスレッド毎に扱うメモリと、大域のメインメモリとのメモリI/Oについて見ていきたいと思います。メモリバリアが理解できれば、以下のソース*1のスレッドがな
マルチコア時代に備えて本気でメモリモデルを理解しておこう - リオーダー & finalフィールド 編 - - かとじゅんの技術日誌
長い文章になってしまったので、概要だけ先に書きます。 以下のJavaプログラムは、常に上から下に順番に命令が実行されると思いますか？つまり、aに1が格納された後に、bに2が格納されると思いますか？ 実は場合によってはこの実行順序が入れ替わる場合があります。これはJavaの言語仕様として定義されていることです。これを考慮しないと信頼性のある並行処理は実装できません。 気になる人は以下を読んでみてください。 a = 1; b = 2; すでにインターネットは社会インフラ化しています。ソーシャルネットワークで多くの人とコミュケーションやコラボレーションできる時代で、個人が情報を作り消費することは当たり前になってきています。そして、インターネット上のコンテンツは増加の一途を辿っています。「情報爆発」なんて言葉も耳慣れた言葉になりましたが、その問題解決のためにMapReduceなどの分散処理技術に注
非検査例外に萌えるわけ - かとじゅんの技術日誌
検査例外はアジャイルやオブジェクト指向の考えに反するという事実 - じゅんいち☆かとうの技術日誌 タイトルは釣り度が強すぎかなー、、、まぁ、個人のブログなんで気にしないでくださいw ブログはカジュアルに書けばいいんですよ。タイトル付け失敗してもサーセンです。 「オブジェクト指向の考え」ではなく「オープンクローズド原則」に反するとしたほうがいいですね。 しかし、貶める気もない人に 貶めるという定義付けは いただけないなー。 で、そんなこんなで重量級をゲットしてもた。。 非チェック例外多用作戦のトレードオフ認識 - 都元ダイスケ IT-PRESS オブジェクト指向と型システムの狭間で例外を考える - プログラマーの脳みそ エントリをいただいたので、さらにまた考えてみました。 チェック例外の正当性を再検証する 最近、多くの人の尊敬を集めているBruce EckelやRod Johnsonといった
意図に関係する大事なことがら - かとじゅんの技術日誌
最近、DDDの"意図の明白なインタフェース"というパターンの章を読みなおしています。このパターンが一環して主張していることは"名前が重要"ということです。その名前の重要性について、いろいろな文献からの引用を用いて考えてみたいと思います。 名前重要 "名前が重要"といえば、「プログラマが知るべき97のこと」で、まつもと ゆきひろ氏が 「名前重要」というタイトルで名前の重要性について語っています。 適切な名前をつけられると言うことは、その機能が正しく理解されて、設計されているということで、逆にふさわしい名前がつけられないということは、その機能が果たすべき役割を設計者自身も十分に理解できていないということではないでしょうか。 名前が設計と強く結び付いていることがわかる、深イイ言葉です。 名前の決定が難航すると「えぃ、面倒だから適当に名前を付けてしまえ」となりがちです。油断すると結構適当になるもん
副作用を最小限に抑えるために必要なこと - かとじゅんの技術日誌
若干、難しい話ですが、設計力を上げたいプログラマ向けなエントリ。私も道半ばです。一緒に考えていただければ幸いです。 堅牢なアプリケーションを実現する上で「副作用を最小限に抑える」という設計思想は、非常に重要な示唆を含んでいます。 その「副作用」とは、そもそもどんな定義なのでしょうか。 DDDでは"side effect"と定義していて、以下のように解説されています。 Domain-Driven Design: Tackling Complexity in the Heart of Software: Evans, Eric: 8601300201665: Amazon.com: Books エリック・エヴァンスのドメイン駆動設計 作者:Eric Evans翔泳社Amazon P250より引用 In standard English, the term side effect implies
スレッドセーフにするために考えること 〜基礎編〜 - かとじゅんの技術日誌
ええっと、リクエストされたので、今回は並行処理ネタにいってみます。 並行処理といえば、この本は必読書ですね。でも、書いてることは、かなりムズカシイデス(´・ω・｀) Java並行処理プログラミング ―その「基盤」と「最新API」を究める― 作者: Brian Goetz,Joshua Bloch,Doug Lea出版社/メーカー: ソフトバンククリエイティブ発売日: 2006/11/22メディア: 単行本購入: 24人 クリック: 419回この商品を含むブログ (163件) を見る ということで、並行処理について、もうちょっと優しく分かりやすく解説できないか考えて書いてみます。 スレッドセーフにするには 今回は、プログラムをスレッドセーフにするためにどんなことを考えればよいか。そういうテーマです。 アンスレッドセーフなコードから この本の最初の方に、"スレッドのリスク"という章で、スレッド
nullという値は本当に必要か考えよう - かとじゅんの技術日誌
今回は、nullの扱いは気をつけようねというお話。特にこれからの人に読んでもらいたい。 nullは変数を初期化する時などに、当たり前のように登場します。Javaではnullがないなんて考えられないわけです。(C#でも同様) しかし、nullの考案者のTony Hoareは「10億ドル単位の過ち」と発言しています。 null参照の考案は10億ドル単位の過ち？(スラッシュドット・ジャパン) - エキサイトニュース nullには、それだけの魔性があって使い方を考える必要があります。nullは”値が存在しない”という状態を表現する時に使われることが多いのですが、そのnullに対する注意が十分に払えずにトラブってしまうことが多いのです。Scalaではその"値が存在しない"という状態をOption型のNoneで表現することでnullを回避する手段が提供されています。JavaではScalaのようにはでき
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
