2.9.2　GC制御の処理の流れ

GC制御は次の流れで処理されます。

図2‒15　GC制御の処理の流れ

それぞれの処理について説明します。

〈この項の構成〉

(1)　メモリ監視

監視タイマスレッドはJavaVMのメモリを監視し，次のどれかの条件を満たす場合，GC制御機能にGCの実行要求を出します。

SerialGCが有効な場合

G1GCが有効な場合

ZGCが有効な場合

GC実行が要求されると，GC制御機能は，バッチアプリケーションが使用しているコネクションを調査します。コネクションの調査では，バッチアプリケーションがリソース排他中かどうかを確認します。

次の表にリソースの排他中と見なす状態を示します。

表2‒28　リソースの排他中と見なす状態
トランザクション	状態		DB Connector	JDBC
トランザクション外	SQL文を実行中^※1	java.sql.Statement#executeの実行中 java.sql.Statement#executeUpdateの実行中 java.sql.Statement#executeQueryの実行中 java.sql.Statement#executeBatchの実行中	○	×
	ResultSetに対する操作中	java.sql.ResultSet#deleteRowの実行中 java.sql.ResultSet#insertRowの実行中 java.sql.ResultSet#updateRowの実行中	○	×
	オブジェクト取得などの操作中^※1	java.sql.Statement#addBatchの実行中 java.sql.Connection#prepareCallの実行中 java.sql.Connection#prepareStatementの実行中	○	×
トランザクション中	Connection APIによるトランザクション実行中^※2 ローカルトランザクション（JTA）実行中^※2		○	×
トランザクション中	グローバルトランザクション（JTA）実行中		−	−

（凡例）○：リソース排他中として扱う　×：リソース排他がないものとして扱う

　　　　−：該当しない

注※1　表中のjava.sql.Statementは，サブインタフェースであるjava.sql.PreparedStatement，java.sql.CallableStatementを含みます。

注※2　トランザクションの開始後（setAutoCommit(false)やUserTransaction.beginの実行後），SQL文の実行またはResultSetに対する操作を1回以上実行していて，トランザクションの決着処理が完了していない状態を指します。

JDBCを使用したリソース操作については，リソース排他がないものとして扱われます。例えば，JDBCのSQL文の実行と，DB Connectorでのトランザクション処理が混在するプログラムを実行した場合，DB Connectorのトランザクション処理だけがGC制御の対象となります。

リソース排他中と判断されると，メッセージKDJE55024-Iを出力して，FullGCの実行待ち状態になります。リソース排他が一つでもあると，FullGCは待機し続けます。FullGC実行待ちの例を次の図に示します。

図2‒16　FullGC実行待ちの例

この図では，一つのジョブプログラム中で二つのリソースにアクセスしています。リソース排他中にFullGCの実行が要求されると，GC制御機能はFullGCの実行を待機状態にします。二つのリソースアクセスが終了するcon2.commit()が実行されると，排他が解除されます。

リソース排他がなくなると，FullGCが実行されます。

同時に実行できるバッチアプリケーションは一つだけです。
一つのバッチアプリケーションから複数のリソースへの処理ができます。ただし，グローバルトランザクションは使用できません。
FullGCの実行待ち状態でも，空きメモリが不足すると，JavaVMによってFullGCが実行されることがあります。これは，GC実行時のメモリ使用量のしきい値が大きい場合や，リソースの排他区間が長い場合などに発生します。マニュアル「アプリケーションサーバシステム設計ガイド」の「9.4　GC制御で使用するしきい値を設定する」を参照して，メモリ使用量のしきい値をチューニングしてください。