JSR 236 Concurrency Utilities for Java EEは何が嬉しいのか
これはJava EE Advent Calendar 2015の6日目です。
Java SEの世界では自由にスレッドを生成することができましたが、Java EEの世界ではユーザーが自分たちでスレッドを新しく立ち上げることは大きな制限がありました。
JSR 236 Concurrency Utilities for Java EEではコンテナ管理されたスレッドプールを元から用意しておくことでユーザーが非同期処理を行えるようにしました。
何が嬉しいのでしょうか。
もともとウェブアクセスからの非同期実行を行うために生み出されたJava EE
Java EE自体は複数人の同時使用を想定した仕様となっているため、もともと非同期処理を意識した仕様となっています。
サーバーのほうで処理をするためのスレッドを最初から起動させておき、リクエストが来る度にスレッドをリクエストに割り当ててレスポンスを生成します。この時割り当てられるスレッドはワーカースレッドと呼ばれます。
例えばTomcatの場合だとserver.xmlで設定ができます。デフォルトでは初期値では10、最大値として200が設定されています。ワーカースレッドは最初は10スレッド作られ、クライアントからのリクエスト数に応じて最大で200スレッドまで生成され、リクエストをさばくことができます。
https://tomcat.apache.org/tomcat-8.0-doc/config/http.html
Concurrency Utilities for Java EEはどのような場合に使うのか
Java Eではすでに非同期処理を行う仕様の上で構築されていますが、その上にConcurrency Utilities for Java EEが生まれました。こちらは何のために使用するものなのでしょうか。
一言で言えば、特定の処理でのサーバーのリソース消費をコントロールするために使います。
たとえば、特定の処理で巨大なCSVファイルを動的に生成しています。その処理はものすごいリソースを消費します。そういった場合、その処理以外の機能を使ってる人へのレスポンスが遅くなるということが考えられます。
そういった影響を少なくするためには、巨大なCSVファイルを生成しているスレッドのPriorityを下げて、他の処理よりも優先度を下げて処理をさせるといったことが考えられます。
Concurrency Utilities for Java EEはAPIの仕様化しかされていないので判りにくいのですが、Java EEを実装しているアプリケーションサーバーではConcurrency Utilities for Java EEでプールしているスレッドに対してのPriorityやスレッド数等についてカスタマイズできるようになっています。
リソースの制限を行えるようにすることで、巨大な処理を行っている最中もサーバーが応答を返せるようにしたり、逆にすべての応答をしないようにするようなセッティングができるようになっているのです。
こちらの設定をしないまま、別スレッドで行っておけば良いんだぜーみたいな話だけだと片手落ちになりますのでご注意ください。
WebLogicの設定例だと以下に記載があります。
https://blogs.oracle.com/WebLogicServer/entry/concurrency_utilities_support_in_weblogic1
