札幌Javaコミュニティ第９回勉強会

月１のJava勉強会でした。午前中はNetBeansを使ったSwingの話、午後はEffective Javaの読書会です。
参加者は合計で10名！このくらいで安定して開催していければいいですね。

NetBeansを使ったSwingアプリ開発入門

NetBeansでデモをしつつ先日のエントリーをベースにSwingアプリの作り方についてお話しました。

• NetBeansを使ったSwingアプリケーション開発 - やさしいデスマーチ
• Swingでのレイアウトの組み方 - やさしいデスマーチ
• NetBeansによるGUIアプリケーションの構築（１） - やさしいデスマーチ
• GUIの設計パターン - やさしいデスマーチ

試みとしては成功かなと思います。どうしてもブログのエントリーですと、具体的なイメージが沸かなかったり、自分で試そうとしたら上手く動かなかったりするわけで、ハンズオン形式で実際に動かしながら試すのは効果的なのかなと思います。特にコード生成がこんな感じになっているとか、リファクタリングで自動生成コードがどう変わるなど、ダイナミックに見せることができたのでいい感じにNetBeansに興味を持たせることができたと思います。また、エントリーは復習用の資料としても使えるのでこの形式は今後も続けたいかと考えてます*1。

Effective Java 読書会

Effective Javaの読書会も今回で４回目ですが、毎回１２ページ程度づつとスローペースで進んでいます。毎回参加できない人もいますし、気になりそうな話題は実際にコーディングしながら進めていくので、Javaの習熟度に寄らず学べるようにしています*2。

項目５ 不必要なオブジェクトの生成を避ける

必要以上にオブジェクトを生成すると、生成コストとGCのコストでパフォーマンスが著しく劣化する場合があり、時には再利用等も考慮しましょう、という話題です。しかし、本当に必要な時かどうかは見極める事が重要で、一般的にパフォーマンスに問題が発生した後、ボトルネックを探し、ボトルネックであったならば改善するといった手順を行うことが重要です。最初からパフォーマンスを意識しすぎてはいけません。特に最近のVMは実行時にパフォーマンスを最適にするような仕組みが組み込まれている為、小手先技を組み込むほうが遅くなるケースもあるようです。
また、Boxing/Unboxingのように知識不足により無駄にオブジェクトを生成してしまっているケースもあります(P23)。実際に自分のMacbookでコードを実行したところ、本とほぼ同じ43秒の時間がかかっていました。オブジェクトの生成も問題ですが、GCのコストも大きいでしょう。ところが、改善したコードは約７秒どころか２ミリ秒の実行速度でした。これはEffective Javaが書かれた頃のVMと現在のVMの性能の違い（MacのJava6は64bit）でしょう。改善前がほとんど変わらなかった為、劇的過ぎる改善に驚きでした。

long start = System.currentTimeMillis();
Long sum = 0L;
for (int i = 0; i < Integer.MAX_VALUE; i++) {
	sum += i;
}
System.out.println(System.currentTimeMillis() - start);

他の環境でも試した比較表になります。

	Effecive Java		43.2秒		6.8秒
	64bit Java6, 2.0GHz Intel Core 2 Duo		43秒		2ミリ秒		Macbook
	32bit Java5, 2.0GHz Intel Core 2 Duo		66.4秒		10.8秒		Macbook
	32bit Java6, 2.4GHz Core2(Quad) Q6600		31.1秒		4.3秒		WindowsXP
	32bit Java5, 2.4GHz Core2(Quad) Q6600		39.9秒		8.1秒		WindowsXP

Java5とJava6でもここまで実行速度の差があるのは驚きですが、それより64bit版はまさに次元が違うｗｗｗ
関連エントリ：Autoboxing/Unboxing - やさしいデスマーチ

追記

トラバで指摘もありましたが、64bitVMで64bit整数を扱っている為に爆速となっていると思われます。
主張したかったのは、64bitだとさらに差が顕著になりますよという事です。説明不足でした。

項目６ 廃れたオブジェクト参照を取り除く

この項目では独自でメモリ管理をやっている場合やキャッシュなどを実装している場合、もう使われることのない参照を持っていることでメモリリークとなりえるという話題です。独自のスタックを作るケースは稀ですが、簡単なキャッシュは偶に実装することもあります。そのような場合は弱参照を使っておく事で対策になります。
この問題は並列処理（スレッドセーフ）と同様に後から発見・対策することが非常に難しい問題です。事前に発生しないような設計・実装をしておく事が重要な問題です。

項目７ ファイナライザを避ける

ファイナライザは、予測不可能で、たいていは危険であり、一般には必要がありません。

ファイナライザは、予測不可能で、たいていは危険であり、一般には必要がありません。

ファイナライザは、予測不可能で、たいていは危険であり、一般には必要がありません。

大切な事なので３回言いました。
勉強会では軽く内容を読みましたが、独自の入力ストリームを実装するとか、そんな状況になったら思い出しましょう。

アフター

会場は５時までなので、終了後は近くのショッピングセンターのカフェコーナーにてノンアルコール懇親会が定番になりつつあります。毎回飲み会だと懐に厳しいですし、流石に５時半から飲むってのはあれなので札幌Javaコミュニティでの飲み会は専門部署（日本Adndroidの会札幌支部）にて行う事が多いです（２〜３ヶ月に1回程度）。勿論、希望があればやりますよ。
今回も様々なガジェットが出てくるid:sumimの独壇場でした。JabraのBluetoothイアホンいいなー。

*1:資料用意するのも楽です

*2:熟練者にはあまり学ぶところはありませんが