WebSocket、組み込み、並列処理で進化するJava、そして最強のIDEはどれだ？：Java Day Tokyo 2013まとめレポート（2）（3/5 ページ）

» 2013年06月11日 18時00分公開

[山本裕介，株式会社サムライズム]

エンタープライズ環境におけるマルチスレッド／並列処理の過去・現在・未来

　このセッションでは日本オラクル製品事業統括 Fusion Middleware事業統括本部 Javaエバンジェリスト寺田佳央氏がJava SEとJava EEにおけるマルチスレッド処理の実装方式の歴史の変遷をひも解くとともに、Java EE 7で可能になる並列処理の実装方法を説明した。

　まずはJavaは言語・ランタイムでネイティブにスレッドプログラミングをサポートしており、ネットワークとの親和性も相まって聡明期よりマルチスレッドのネットワークアプリケーションなどが数多く登場したことを紹介。

Javaは登場時よりスレッドプログラミングが可能であった

マルチスレッドプログラミングをより効率的に行えるJSR-166yやJSR-166eの導入

　そして古典的なマルチスレッドのプログラミングではThreadクラスやRunnableインターフェイスを使ってアプリケーションでスレッドの起動や管理を行っていたが、非効率な実装になることが多いのでJSR-166／Java SE 5で導入されたConcurrency Utilitiesの利用を強く勧めた。

リクエストごとにスレッドを起動するアンチパターン

　デモでは、Concurrency Utilitiesを利用することで独自にスレッドプールを実装することなくメニーコアのCPU資源を十分に使い切ることができることを証明した。

Concurrency Utilities活用で256ものCPUがあるサーバリソースを使い切る様子（MOV形式動画、クリックするとQuickTimeプレイヤーで再生）

　またJava SE 7で導入されたJSR-166y、そしてJava SE 8で導入されるJSR-166eにより非同期、並列処理のプログラミングは一層容易になっておりメニイコアのアーキテクチャで確実にスケールアップする完成されたプラットフォームであることを強調した。

　しかしJava EEの世界ではアプリケーション管理のスレッドを立ち上げることは許されておらず、非同期処理を行うには、これまでJMS／MDBを利用する必要があった。またJMSは、堅牢なフレームワークではあるものの、メッセージの送受信に煩雑なコードが必要であったという問題もある。

　そこで、Java EE 7導入されるJMS 2.0によりアノテーションを活用することで非常にシンプルになったコードを寺田氏は披露した。

JMS 2.0により圧倒的に簡素化されたコード

　次いでアプリケーションスレッドを作れないことに対する解としてJava EE 7で導入される機能を紹介した。これまで非同期処理、特にスケジューリングをするにはオープンソースの「Quartz Scheduler」や、決して使いやすいとはいえない「EJB Timer」を使う必要があった。実際のところJavaにこだわらずCronでバッチ処理を呼び出すようにしているシステムも多いのではないだろうか。

　Java EE 7で導入されるJSR-236ではJava EEアプリケーションサーバ上で標準化された仕組みで非同期処理、タスクスケジューリングを行えるようになる。