導入/問題提起：なぜあなたのJavaバッチは「遅い」のか？
プロジェクトの最終段階やシステムリプレース時、インフラエンジニアから「このバッチ処理、CPUがほとんど使われていないのに時間がかかりすぎている」と指摘を受けたことはありませんか？
特に月次の請求や支払を確定させるような締め処理を行うJavaシステムで、データ件数が増えるほど処理時間が延びていく場合、その原因は単なる「データ量の増加」ではなく、「CPUリソースを使いこなせていない」、つまりアプリケーション設計の非効率性にある可能性が高いです。
本記事では、シングルスレッドで動作するJavaバッチの根本的な問題点を解説し、CPUリソースを最大限に活用し、処理時間を劇的に短縮するための具体的なアプローチを解説します。
技術的解説：CPU使用率100%は「頑張っている証拠」
1. シングルスレッド処理の限界
特に何も考慮せずに作成されたJavaバッチ処理は、デフォルトでシングルスレッドで動作します。
現代のサーバーCPUは複数のコアを持っていますが、シングルスレッドではそのうちたった1つのコアしか使えません。残りのコアは遊んでいる状態（アイドル状態）です。
| 問題点 | 詳細 | 結果 |
|---|---|---|
| コアの活用不足 | マルチコアCPUの能力を最大1/4～1/8程度しか引き出せない。 | 全体のCPU使用率が低く、処理が非効率になる。 |
| I/O待ち時間の発生 | データベースへのアクセス（I/O）中はCPUが待機し、計算を進められない（I/Oバウンド）。 | 処理の大部分が「待機時間」となり、CPUは働けていない。 |
| 逐次処理 | 全ての顧客の処理が「1件目 → 2件目 → 3件目」と順番待ちになる。 | 処理量が膨大になると、完了までに指数関数的に時間がかかる。 |
バッチ処理を開始してからCPU全体の使用率が例えばCPUのコア数4の場合は25%前後で張り付いていればこの記事の内容が当てはまる可能性が非常に高いです。
2. CPU使用率100%が高評価となる技術的意義
インフラエンジニアが「良い」と評価するシステム、すなわちCPU使用率が100%に近い状態で動作し、短時間で終わるアプリケーションは、以下の工夫が成功していることを示します。
- リソースの最大活用: 複数のCPUコアすべてに仕事を割り当て、計算能力を使い切っている。
- 並行処理の成功: 処理を細かく分割し、すべてのコアで並列に実行している。
- I/O待ち時間の隠蔽: データベースアクセスで一つのスレッドが待機している間に、別のスレッドが計算を進めている（並行性）。これにより、CPUがアイドルになる時間を極限まで減らし、リソースをフル稼働させている。
締め処理のように大量の独立したデータを扱う処理においては、CPUをフル稼働させることは、リソースを無駄にせず、最短時間で処理を終えるための必須条件なのです。
解決策：簡単かつ安全に高速化！ExecutorServiceによる並行化
シングルスレッドで動作しているJavaバッチを、比較的安全かつ管理しやすい形で並行処理に移行するためのアプローチは、Java標準ライブラリのjava.util.concurrent.ExecutorServiceを利用することです。
移行手順の概要
- タスクの切り出し: 顧客単位の請求計算など、独立して実行できる最小単位の処理をRunnableまたはCallableとして切り出します。
- スレッドプールの生成: ExecutorService（例: Executors.newFixedThreadPool(4)など）を作成し、スレッドの数（CPUコア数などを参考に）を制限します。
- タスクの投入: メインスレッドから、切り出したタスクをスレッドプールに投入（submit()）します。
- 完了待ち: すべてのタスクが完了するのを待機し、リソースを解放します。
ExecutorServiceはスレッドの生成や管理を自動で行うため、スレッドを直接操作するよりも安全性が高く、CPUリソースを効率的に利用できます。
【注意】安易な並行化はデータを壊す！安全な移行のための3つのチェックポイント
並行処理への移行は高速化を実現しますが、特に何も考えずに実装するとデータ破損やデッドロックという深刻なバグを引き起こします。以下の3点を必ず確認してください。
1. 共有リソースへのアクセス制御
複数のスレッドが同時に同じデータ（カウンター、キャッシュなど）に書き込もうとすると、**競合状態（Race Condition）**が発生し、データが不整合を起こします。
- 対策:
- 並行コレクションの利用: HashMapの代わりにConcurrentHashMapを使用するなど、java.util.concurrentパッケージのコレクションクラスを利用する。
- 不変オブジェクト（Immutable Object）: スレッド間で共有するデータは、作成後に変更できない不変オブジェクトとして設計する。これが最も安全です。
2. トランザクション境界の維持
締め処理において、特定の顧客の処理がDBへの複数の書き込みで構成される場合、それらは一つのトランザクションとして扱われる必要があります。タスクを分割した結果、トランザクションの境界がスレッドをまたいでしまわないよう注意が必要です。
- 対策: 処理の最小単位（タスク）は、単一のコミット（あるいはロールバック）で完結する論理的なトランザクションとなるように設計する。
3. スレッド切り替えコストの考慮
タスクを細かすぎたり、スレッド数をコア数以上に増やしすぎたりすると、OSがスレッドを切り替えるコスト（コンテキストスイッチ）が計算コストを上回り、かえって遅くなる場合があります。
- 対策: 最初は「CPUコア数」を目安にスレッド数を設定し、処理時間とCPU使用率を計測しながら、最適なスレッド数を見極めるパフォーマンステストを必ず行う。
総括：インフラが指摘するボトルネック
インフラエンジニアの指摘する「CPU使用率が低い」という現象は、 「システムに搭載されたリソースを効率的に利用できていない」 というアプリケーション側の設計ミスを浮き彫りにします。
現代のアプリケーションエンジニアには、単に機能を実現するだけでなく、 「データ量が増えたとき」「サーバーコストを削減したいとき」 にシステムの性能がどうボトルネックになるかを予測し、CPU効率という観点で設計できる能力が求められています。
締め処理の高速化は、この 「リソース効率」 の意識を持つための最適なケーススタディです。あなたのJavaバッチのCPUが遊んでいないか、ぜひ一度チェックしてみてください。
補足：Springフレームワークの場合
Springフレームワークを使っている場合、特にバッチ処理やWebアプリケーションにおいては、並行処理や性能設計の考え方が少し異なります。
Springが提供する抽象化と自動化の機能により、並行処理の「実装」自体は楽になりますが、 「設計上の考慮事項」 はより重要になります。
1. Spring Batchによる自動化と簡略化
月次の締め処理のような大量データ処理を行う場合、Springフレームワークでは通常、専用のライブラリであるSpring Batchを利用します。
- 並行処理の抽象化: Spring Batchは、データ読み込み、処理、書き込み（ItemReader, ItemProcessor, ItemWriter）のステップを明確に分離します。
- マルチスレッディング: 非常に強力な機能として、設定ファイルやJavaコードでTaskExecutor（実体はExecutorService）を指定するだけで、処理ステップの並列実行（Multi-threaded Step）やパーティショニング（Partitioning: データを分割して複数のスレーブプロセスで並行処理）を簡単に実現できます。
違い: 素のJavaではExecutorServiceやCallableを自前で実装・管理する必要がありますが、Spring Batchでは設定一つでフレームワークが安全にスレッドやプロセスを管理してくれます。これにより、CPU使用率を100%に近づけるための実装難易度は劇的に下がります。
2. Web環境（Spring Boot）での並行性
一般的なWebアプリケーション（Spring Boot）の場合、並行処理の考え方が変わります。
- リクエストごとのスレッド: Spring MVC（Webアプリケーション）では、通常、各クライアントからのリクエストはTomcatなどのWebコンテナによってスレッドが割り当てられ、並行して処理されます。開発者が意識的にマルチスレッドを実装しなくても、Webサービス全体としては並行して動いています。
- 非同期処理: 高速化が必要な特定の処理（外部API呼び出しや重い計算）には、@Asyncアノテーションを使うことで、そのメソッドの実行を別のスレッドプールに任せ、メインスレッド（リクエスト処理スレッド）を早く解放できます。
違い: WebアプリのAEは、「サーバー全体の並行処理」よりも、「リクエストスレッドをブロックしない」ための非同期（ノンブロッキング）処理を意識するようになります。これにより、CPUを効率的に利用し、多くのリクエストをさばけるようになります。
3. より重要になる「状態管理」と「スコープ」
Springを使うことで実装は楽になりますが、並行処理の安全性に関する考慮事項はより厳密になります。
| 考慮事項 | 詳細 | Springでの注意点 |
|---|---|---|
| スレッドセーフティ | 複数のスレッドから同時にアクセスされてもデータが壊れないこと。 | Springのコンポーネントはデフォルトでシングルトン（一つのインスタンスを共有）です。インスタンス変数（フィールド）に可変のデータを持つと、並行処理で競合状態になるリスクがあります。 |
| トランザクション | 処理の論理的な一貫性を保つこと。 | Spring Batchでは、処理単位（チャンク）ごとにトランザクションが自動管理されますが、並行処理を行う際は、各スレッド/プロセスが独立したトランザクションを持つように設定する必要があります。 |
結論として、Springフレームワークは並行処理の 「実装」のハードルを下げる強力なツールですが、シングルトンやトランザクションといったフレームワークの特性を理解し、「状態を持たない（ステートレス）設計」 を徹底することが、安全にCPUリソースを使い切るための鍵となります。