「java」タグアーカイブ

ログ出力が一気に効率化！log4j2を使うべき場面とは

2025年10月2日管理者コメントする

Java開発におけるログ出力は、障害解析・性能改善・監査の三種の神器。長年使われてきた log4j 1.x に対し、後継の log4j2 は「高速・柔軟・安全」に大幅進化しています。本稿では、違いが直感的に分かる比較と、**失敗しない導入手順（Maven/Gradle、設定、非同期化、移行の落とし穴まで）**をまとめます。

1. log4j 1.x と log4j2 の要点比較

観点	log4j 1.x	log4j2
パフォーマンス	同期中心。大量ログでアプリに負荷	LMAX Disruptorによる非同期ロガーで高速・低レイテンシ
設定形式	properties / XML のみ	XML / JSON / YAML / properties、ホットリロード対応
非同期化	AsyncAppenderのみ	AsyncAppender＋Async Logger（全ロガー非同期も可）
GC負荷	文字列連結が発生しやすくGC負担増	遅延評価（ラムダ/プレースホルダ）で不要時は連結処理なし
拡張性	限定的	フィルタ / レイアウト / Appender が豊富（JSON出力、Failover等）
メンテナンス	EoL（保守終了）	現行バージョン維持（常に最新2.xを推奨）

結論：高負荷・可観測性重視の現場ほど log4j2 一択。

2. こんな場面で「log4j2」を選ぶ

大量ログ（秒間1000件～万件）を裁くWeb/バッチ、IoT、決済、EC
本番でログレベルを動的変更したい（再起動なしで即調査）
JSON出力で Elasticsearch / OpenSearch / Splunk / Datadog に流す
遅延評価や MDC（相関ID） で可観測性とパフォーマンスを両立したい

3. 導入手順（Maven/Gradle）――最短で“動く”まで

ここでは log4j2 を実装（Core）として使い、APIは SLF4J で書く構成を推奨します。
理由：ライブラリ間の共通言語として SLF4J がデファクト、実装差し替えも容易。

3.1 依存関係を追加

Maven（pom.xml）

<dependencies>
  <!-- SLF4J API -->
  <dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
  </dependency>

  <!-- Log4j2 実装（Core）＋ API -->
  <dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
  </dependency>
  <dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-api</artifactId>
  </dependency>

  <!-- SLF4J → Log4j2 バインド（SLF4J 2.x 用） -->
  <dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-slf4j2-impl</artifactId>
  </dependency>

  <!-- （任意）Async Logger 用：Disruptor -->
  <dependency>
    <groupId>com.lmax</groupId>
    <artifactId>disruptor</artifactId>
  </dependency>
</dependencies>

</dependency>

<groupId>org.apache.logging.log4j</groupId>

</dependency>

<groupId>org.apache.logging.log4j</groupId>

</dependency>

<groupId>org.apache.logging.log4j</groupId>

</dependency>

<artifactId>disruptor</artifactId>

</dependency>

</dependencies>

Gradle（Kotlin DSL）

dependencies {
    implementation("org.slf4j:slf4j-api")
    implementation("org.apache.logging.log4j:log4j-core")
    implementation("org.apache.logging.log4j:log4j-api")
    implementation("org.apache.logging.log4j:log4j-slf4j2-impl")
    implementation("com.lmax:disruptor") // Async Logger を使うなら
}

dependencies {

implementation("org.slf4j:slf4j-api")

implementation("org.apache.logging.log4j:log4j-core")

implementation("org.apache.logging.log4j:log4j-api")

implementation("org.apache.logging.log4j:log4j-slf4j2-impl")

implementation("com.lmax:disruptor") // Async Logger を使うなら

}

重要：既存で引き込まれる logback-classic や slf4j-log4j12 は除外してください（重複実装エラー＆二重出力の原因）。

3.2 旧実装の衝突を避ける（例：Maven の除外）

<dependency>
  <groupId>some.group</groupId>
  <artifactId>some-lib</artifactId>
  <exclusions>
    <exclusion>
      <groupId>ch.qos.logback</groupId>
      <artifactId>logback-classic</artifactId>
    </exclusion>
    <exclusion>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-log4j12</artifactId>
    </exclusion>
    <exclusion>
      <groupId>log4j</groupId>
      <artifactId>log4j</artifactId>
    </exclusion>
  </exclusions>
</dependency>

<groupId>some.group</groupId>

<groupId>ch.qos.logback</groupId>

<artifactId>logback-classic</artifactId>

</exclusion>

</exclusion>

</exclusion>

</exclusions>

</dependency>

3.3 最小構成の設定ファイル（`src/main/resources/log4j2.xml`）

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN" monitorInterval="30">
  <Appenders>
    <Console name="Console" target="SYSTEM_OUT">
      <PatternLayout pattern="%d{ISO8601} [%t] %-5level %logger - %msg%n"/>
    </Console>
  </Appenders>
  <Loggers>
    <Root level="INFO">
      <AppenderRef ref="Console"/>
    </Root>
  </Loggers>
</Configuration>

<?xml version="1.0" encoding="UTF-8"?>

</Console>

</Appenders>

</Root>

</Loggers>

</Configuration>

monitorInterval="30"：30秒ごとに設定ファイルの変更を検知し、再起動なしで反映。

3.4 SLF4J での利用コード

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class App {
  private static final Logger log = LoggerFactory.getLogger(App.class);

  public static void main(String[] args) {
    String userId = "alice";
    log.info("Hello, {}", userId);           // プレースホルダで連結コスト削減
    log.debug("Detail: {}", () -> heavy());  // ラムダで遅延評価（DEBUGでなければ実行されない）
  }

  private static String heavy() { /* 重い処理 */ return "ok"; }
}

import org.slf4j.Logger;

import org.slf4j.LoggerFactory;

public class App {

private static final Logger log = LoggerFactory.getLogger(App.class);

public static void main(String[] args) {

String userId = "alice";

log.info("Hello, {}", userId); // プレースホルダで連結コスト削減

log.debug("Detail: {}", () -> heavy()); // ラムダで遅延評価（DEBUGでなければ実行されない）

}

private static String heavy() { /* 重い処理 */ return "ok"; }

}

3.5 ローリングファイル＋JSON（実戦向け）

<Configuration status="WARN" monitorInterval="30">
  <Appenders>
    <RollingFile name="AppLog" fileName="logs/app.log"
                 filePattern="logs/app-%d{yyyy-MM-dd}-%i.log.gz">
      <JsonLayout complete="false" compact="true" eventEol="true"/>
      <Policies>
        <SizeBasedTriggeringPolicy size="50 MB"/>
        <TimeBasedTriggeringPolicy/>
      </Policies>
      <DefaultRolloverStrategy max="30"/>
    </RollingFile>
  </Appenders>
  <Loggers>
    <Root level="INFO">
      <AppenderRef ref="AppLog"/>
    </Root>
  </Loggers>
</Configuration>

<RollingFile name="AppLog" fileName="logs/app.log"

filePattern="logs/app-%d{yyyy-MM-dd}-%i.log.gz">

</Policies>

</RollingFile>

</Appenders>

</Root>

</Loggers>

</Configuration>

JSON出力で可観測性基盤にそのまま投入可能。
max="30"：古いファイルを30世代で自動削除。

3.6 非同期化の推奨設定（高スループット向け）

方法A：Async Appender（部分的に非同期）

方法B：Async Logger（全ロガーを非同期化）

依存に disruptor を追加（前述）
JVM 起動オプションに以下を付与

INI

-DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector

1

-DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector

目安：秒間数千件以上のログ、遅延許容な処理では Async Logger が強力。
低遅延の必要なクリティカル処理（トランザクション境界直前など）は同期Appenderで分離も可。

3.7 現場で必須の“相関ID”（MDC/ThreadContext）

分散トレーシングやバッチ内のジョブ相関に必須。

3.8 動的なログレベル変更（コード＆設定）

コードで変更

Java

import org.apache.logging.log4j.core.config.Configurator; import org.apache.logging.log4j.Level; Configurator.setLevel("com.example.service", Level.DEBUG);

1
2
3

import org.apache.logging.log4j.core.config.Configurator;
import org.apache.logging.log4j.Level;
Configurator.setLevel("com.example.service", Level.DEBUG);
設定のホットリロード：monitorInterval でファイルを書き換えるだけ

3.9 他フレームワークのログを一本化（任意）

JUL（java.util.logging）→ Log4j2：log4j-jul を追加し、

INI

-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager

1

-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager
Commons Logging（JCL）→ Log4j2：log4j-jcl を追加

4. 旧 log4j 1.x からの移行チェックリスト

jar の置換と衝突解消
- 1.x の log4j-1.2.x.jar を除去
- log4j-api, log4j-core, log4j-slf4j2-impl を追加
- 他実装（logback 等）を除外
設定ファイルを置き換え
- log4j.properties → log4j2.xml（or .json/.yaml） に構造変換
コードの修正方針（推奨順）
- SLF4J API へ書き換え（LoggerFactory.getLogger 等）
- もしくは log4j2 API へ（org.apache.logging.log4j.LogManager.getLogger）
- 当面の暫定策として log4j-1.2-api（互換レイヤ）もあるが恒久利用は非推奨
性能と出力の検証
- 期待QPSでのバックプレッシャやディスク枯渇を確認
- 非同期化の有無でレイテンシ差を測定
運用監視
- -Dlog4j2.debug=true で起動し、設定解決やエラーを起動時に確認
- ログローテーションと世代数の上限を監視に組み込み

5. 開発・運用の実用Tips

重い toString() を直接連結しない：log.debug("x={}", () -> obj.heavyToString())
Failover Appender で出力先障害に備える（ネットワークストレージ等）
パターン設計：時刻、レベル、ロガー、メッセージ、%throwable、MDC を最低限
本番では INFO 以上、詳細調査時のみ一時的に DEBUG/TRACE を開ける
最新 2.x 系を採用（セキュリティ修正が継続されるため）

6. まとめ

log4j2 は “高速＋柔軟＋安全”。大量ログ・可観測性要件に強い。
導入は依存追加 → 設定作成 → 非同期化の3ステップが核。
移行は衝突除去と設定変換が肝。SLF4J API で書くと将来の実装差し替えも容易。

HULFT, Java, ブログ, プログラミング

HULFT連携：Javaからユーティリティコマンドを呼び出す実装例

2025年10月1日管理者コメントする

HULFTには「送受信ジョブを定義して使う方法」以外に、utlsendなどのユーティリティ系コマンドを直接呼び出してファイル転送や加工を行う手段があります。
これらは事前の送受信定義が不要で、コマンド実行時に条件を指定できるため、テスト送信・スポット利用・簡易処理に非常に便利です。

本記事では、JavaでHULFTコマンドを実行する例をご紹介します。

utlsend : ファイル送信
utlrecv : ファイル受信
utlconcat : ファイル連結
utlsplit : ファイル分割

Javaから外部コマンドを実行する基本

Javaでは ProcessBuilder を使うことで、外部のHULFTコマンドを呼び出せます。
エラー出力も標準出力にまとめる設定をすれば、ログ管理が容易になります。

共通の呼び出しテンプレートは以下の通りです。

import java.io.*;

public class HulftCommandRunner {
    public static void runCommand(String... command) {
        try {
            ProcessBuilder pb = new ProcessBuilder(command);
            pb.redirectErrorStream(true);
            Process process = pb.start();

            BufferedReader reader = new BufferedReader(
                    new InputStreamReader(process.getInputStream(), "MS932")); // Windows日本語環境想定
            String line;
            while ((line = reader.readLine()) != null) {
                System.out.println(line);
            }

            int exitCode = process.waitFor();
            System.out.println("終了コード: " + exitCode);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

import java.io.*;

public class HulftCommandRunner {

public static void runCommand(String... command) {

try {

ProcessBuilder pb = new ProcessBuilder(command);

pb.redirectErrorStream(true);

Process process = pb.start();

BufferedReader reader = new BufferedReader(

new InputStreamReader(process.getInputStream(), "MS932")); // Windows日本語環境想定

String line;

while ((line = reader.readLine()) != null) {

System.out.println(line);

}

int exitCode = process.waitFor();

System.out.println("終了コード: " + exitCode);

} catch (Exception e) {

e.printStackTrace();

}

以降の例では、この runCommand を利用して各ユーティリティコマンドを実行します。

1. ファイル送信（`utlsend`）

事前の送信定義が不要で、対象ファイルと宛先ノードを直接指定できます。

public class ExampleSend {
    public static void main(String[] args) {
        HulftCommandRunner.runCommand(
            "utlsend",
            "-f", "/data/test.txt",
            "-n", "NODE001"
        );
    }
}

public class ExampleSend {

public static void main(String[] args) {

HulftCommandRunner.runCommand(

"utlsend",

"-f", "/data/test.txt",

"-n", "NODE001"

);

}

-f : 送信するファイルパス
-n : 宛先ノード名（HULFTに登録済み）

2. ファイル受信（`utlrecv`）

受信ジョブを登録せず、コマンドだけでファイルを取得できます。

public class ExampleRecv {
    public static void main(String[] args) {
        HulftCommandRunner.runCommand(
            "utlrecv",
            "-f", "/data/recv.txt",
            "-n", "NODE001"
        );
    }
}

public class ExampleRecv {

public static void main(String[] args) {

HulftCommandRunner.runCommand(

"utlrecv",

"-f", "/data/recv.txt",

"-n", "NODE001"

);

}

-f : 保存先のファイル名
-n : 送信元ノード名

3. ファイル連結（`utlconcat`）

複数のファイルを1つにまとめたいときに使います。

public class ExampleConcat {
    public static void main(String[] args) {
        HulftCommandRunner.runCommand(
            "utlconcat",
            "-o", "/data/merged.txt",
            "-f", "/data/file1.txt",
            "-f", "/data/file2.txt"
        );
    }
}

public class ExampleConcat {

public static void main(String[] args) {

HulftCommandRunner.runCommand(

"utlconcat",

"-o", "/data/merged.txt",

"-f", "/data/file1.txt",

"-f", "/data/file2.txt"

);

}

-o : 出力ファイル名
-f : 結合対象のファイル（複数指定可）

4. ファイル分割（`utlsplit`）

大きなファイルを分割して処理したいときに使います。

public class ExampleSplit {
    public static void main(String[] args) {
        HulftCommandRunner.runCommand(
            "utlsplit",
            "-f", "/data/bigfile.txt",
            "-l", "1000"
        );
    }
}

public class ExampleSplit {

public static void main(String[] args) {

HulftCommandRunner.runCommand(

"utlsplit",

"-f", "/data/bigfile.txt",

"-l", "1000"

);

}

-f : 分割対象ファイル
-l : 分割する行数（例：1000行ごと）

運用上の注意点

PATHの設定
Javaから呼び出す際は、utlsend.exe などのHULFTバイナリがPATHに通っている必要があります。
通っていない場合はフルパス指定が必須です。
終了コードの確認
- 0 : 正常終了
- 0以外 : エラー（詳細はHULFTマニュアルのエラーコード参照）
ログ管理
実際の業務バッチでは process.getInputStream() の内容をファイル出力してログ管理することを推奨します。

まとめ

utlsend でファイルを即送信できる
utlrecv で即時受信が可能
utlconcat でファイルを連結
utlsplit でファイルを分解

これらをJavaから呼び出すことで、柔軟なファイル連携や加工処理が実現できます。

Java, ブログ

JavaのGC（Garbage Collection）とは？仕組みと注意点

2025年9月26日管理者コメントする

GCとは何か

Java で開発をしていると、よく耳にする「GC（Garbage Collection）」。
これは 不要になったオブジェクトを自動で回収してメモリを解放する仕組み のことです。C言語のように手動で free() を呼ぶ必要はなく、Java VM が裏側でメモリ管理を行います。

ざっくり構造・最近のGC

世代別回収：Eden/Survivor（若世代）→ Old（老世代）
Minor GC：Edenが埋まったら短命オブジェクト中心に回収
Major/Full GC：Oldが逼迫、断片化、クラス/メタ領域逼迫などで広域回収
既定GC：G1GC（Java 9+）。低停止要求は ZGC / Shenandoah も選択肢

主なトリガ

Eden満杯（Minor） / Old高水準（Major）
巨大配列（Humongous）割当て（G1）
System.gc() 明示呼び出し
メタスペース/オフヒープ圧迫（DirectByteBuffer/JNI など）

“悪い例 → 良い例”で学ぶメモリ/GC対策

1) 無制限キャッシュ（静的Map地獄）

悪い例

// Caffeine を例に（依存追加で利用可）
Cache<String, Object> cache = Caffeine.newBuilder()
    .maximumSize(10_000)         // 上限
    .expireAfterAccess(Duration.ofMinutes(30)) // 期限
    .recordStats()
    .build();

public Object get(String key) {
  return cache.get(key, this::loadSlow);
}

// Caffeine を例に（依存追加で利用可）

Cache<String, Object> cache = Caffeine.newBuilder()

.maximumSize(10_000) // 上限

.expireAfterAccess(Duration.ofMinutes(30)) // 期限

.recordStats()

.build();

public Object get(String key) {

return cache.get(key, this::loadSlow);

}

ポイント：上限なしは必ずOldを膨らませる。キャッシュは 容量・期限・エビクションを設計。

2) リスナ/コールバック未解除

悪い例

class View {
  Closeable addListener(Listener l) {
    // 登録...
    return () -> removeListener(l); // try-with-resources で自動解除
  }
}

try (var h = view.addListener(event -> {/*...*/})) {
  // 利用中
} // スコープを出ると自動で removeListener

class View {

Closeable addListener(Listener l) {

// 登録...

return () -> removeListener(l); // try-with-resources で自動解除

}

try (var h = view.addListener(event -> {/*...*/})) {

// 利用中

} // スコープを出ると自動で removeListener

補足：WeakReference リスナはイベント強度低下や意図せぬ解放のリスク。基本は明示解除。

3) `ThreadLocal` の放置（プールスレッドに張り付く）

悪い例

良い例（finallyで確実に除去）

private static final ThreadLocal<byte[]> BUF =
    ThreadLocal.withInitial(() -> new byte[1<<20]);

void work() {
  try {
    var buf = BUF.get();
    // 処理...
  } finally {
    BUF.remove(); // プールスレッドに残さない
  }
}

private static final ThreadLocal<byte[]> BUF =

ThreadLocal.withInitial(() -> new byte[1<<20]);

void work() {

try {

var buf = BUF.get();

// 処理...

} finally {

BUF.remove(); // プールスレッドに残さない

}

ポイント：スレッドプール＝長寿命。remove() を忘れると実質グローバル保持。

4) `System.gc()` 乱用

悪い例

5) ラムダ/内部クラスが外側（巨大オブジェクト）をキャプチャ

悪い例

良い例（必要最小限のデータだけ渡す・static化）

class Holder {
  byte[] big = new byte[10_000_000];

  Runnable r() {
    int len = big.length;        // プリミティブだけ抜き出す
    return () -> System.out.println(len);
  }
}
// あるいは static ネストクラスで暗黙の外部参照を避ける

class Holder {

byte[] big = new byte[10_000_000];

Runnable r() {

int len = big.length; // プリミティブだけ抜き出す

return () -> System.out.println(len);

}

// あるいは static ネストクラスで暗黙の外部参照を避ける

ポイント：キャプチャ=保持。意図せず大物を延命していないか疑う。

6) ループ内の大量一時オブジェクト

悪い例

良い例（StringBuilder再利用・ボクシング回避）

7) finalize/Cleaner頼み（遅延・不確実）

悪い例

class Resource implements AutoCloseable {
  private final FileChannel ch = FileChannel.open(...);
  @Override public void close() throws IOException { ch.close(); }
}

try (Resource r = new Resource()) {
  // 利用
} // ここで必ず解放

class Resource implements AutoCloseable {

private final FileChannel ch = FileChannel.open(...);

@Override public void close() throws IOException { ch.close(); }

}

try (Resource r = new Resource()) {

// 利用

} // ここで必ず解放

8) クラスローダ・アプリ再デプロイ時のリーク

悪い例

良い例（クラスローダ境界を越える参照を断つ）

- static にアプリクラス/インスタンスを保持しない
- ThreadLocal を必ず remove
- Executor/Timer を停止（shutdown）してからアンデプロイ
- JDBC ドライバ/ログアダプタ等の明示的解除を守る

- static にアプリクラス/インスタンスを保持しない

- ThreadLocal を必ず remove

- Executor/Timer を停止（shutdown）してからアンデプロイ

- JDBC ドライバ/ログアダプタ等の明示的解除を守る

9) 巨大配列・Humongous割当ての長期保持（G1）

悪い例

良い例（分割・ストリーミング・寿命短縮）

ポイント：巨大ブロックは断片化と回収コスト増の温床。

10) 無制限のキュー/バッファ

悪い例

良い例（有界＋バックプレッシャ）

BlockingQueue<Event> q = new ArrayBlockingQueue<>(10_000);

boolean offered = q.offer(event, 100, TimeUnit.MILLISECONDS);
if (!offered) {
  // 混雑時の方針：間引き/遅延/古いもの破棄など
}

BlockingQueue<Event> q = new ArrayBlockingQueue<>(10_000);

boolean offered = q.offer(event, 100, TimeUnit.MILLISECONDS);

if (!offered) {

// 混雑時の方針：間引き/遅延/古いもの破棄など

}

GCログ・計測の始め方（JDK 9+）

まずはコードの割当て削減 → その後にヒープ/GC調整
監視：jcmd <pid> GC.heap_info / jstat -gc <pid> 1000
ボトルネック特定：JFR（Java Flight Recorder） で割当てホットスポットを把握
必要なら ZGC/Shenandoah も評価（レイテンシ目標に応じて）

実務チェックリスト（配布推奨）

System.gc() を禁止/抑制
キャッシュ・キューは有界＋期限
ThreadLocal は finally で remove
リスナ/コールバックは確実に解除（AutoCloseable化が効く）
ループ内の一時オブジェクトを減らす（Builder再利用/ボクシング回避）
巨大配列は分割・短命化
クラスローダ境界を跨ぐ静的参照禁止、Executor停止・ドライバ解除
try-with-resourcesでオフヒープ即時解放
GCログ/JFRで事実ベースに調整
目標停止時間（例：MaxGCPauseMillis）を定めて検証

まとめ

GCは“自動”でも“万能”ではありません。
「GCが働きやすいコード」（不要参照を残さない・波及して大物を掴ませない・ピークメモリを避ける）を心がけ、ログ/計測で改善ループを回すのが最短距離です。

Eclipse, Web開発, ソフトウェア, ブログ

Javaのバージョンアップ手順

2022年5月27日管理者コメントする

しばらくJavaのバージョンアップを実施してなかったのでバージョンアップ時の手順をメモしておきます。
今回はJava 1.6.0_45 ⇒1.8.0_331へバージョンアップしてみます。
※2022年5月時点でJavaの最新バージョンは18ですが開発で使用してるのは8なので今回最新版にはしてません。

jdkのダウンロード

Oracleの「Javaアーカイブ」ページからダウンロードする事が可能です。
ダウンロードする場合Oracleアカウントが必要となります。
⇒Oracle Java Archiveページ

jdkのインストール手順

インストールする前にまずは現在適用されているJavaのバージョンを確認します。コマンドプロンプトの画面で「javac -version」と入力すれば現在適用されているJavaのバージョンを確認できます。
OracleのアーカイブページでJavaのバージョンを選択します。今回は「Java SE 8(8u211 and later)」を選択します。
次にjdkのインストーラーを選択します。今回は64ビット版の「jdk-8u331-windows-x64.exe」を選択します。
ダウンロードした「jdk-8u331-windows-x64.exe」を実行してセットアップ画面の「次」ボタンを選択します。
インストール先を変更したい場合は変更ボタンから指定してから「次へ」ボタンを選択します。
インストールが終了するの以下の画面が表示されるので「閉じる」ボタンを選択します。
コントロールパネル ⇒ システム ⇒ システムの詳細設定から環境変更を設定します。
システム環境変数の「JAVA_HOME」を選択しjdkをインストールしたフォルダを指定します。
次にシステム環境変数の「Path」を選択肢jdkのフォルダが指定されている箇所を変更します。
環境変数の設定が完了したら再度コマンドプロンプト画面でJavaのバージョンを確認して値が変更されていればバージョンアップ作業完了です。

Web開発, オブジェクト指向, ブログ

インスタンス変数とローカル変数の違い

2015年2月19日管理者コメントする

Webシステムは基本的に複数人で同時利用されるのが前提のため、マルチスレッドアクセスを考慮した設計・実装を行う必要があります。業務でJavaの各変数とスレッドセーフについて考える機会があったので、「インスタンス変数とローカル変数の違いとスレッドセーフとの関係」について今回は整理してみようと思います。

Javaでの変数毎のメモリ管理イメージ

インスタンス変数とは

サンプルコード

Java

public class ClassSample{ /** インスタンス変数 */ private String hoge; }

1
2
3
4

public class ClassSample{
/** インスタンス変数 */
private String hoge;
}
メソッドの外に記述します。staticは付けません（staticが付くとクラス変数になります）。
ヒープ領域と呼ばれる共有メモリ領域へ保存される為、宣言しただけではスレッドセーフにはなりません。
スレッドセーフを保つ為には初期化する必要があります。
- コンスラクタで初期化
- インスタンス宣言時に初期化
- 最初のget時に初期化
他のスレッドからの更新を防ぐ為、修飾子はprivateにする必要があります。
当該クラス内の任意のメソッドから参照可能となります。

ローカル変数とは

サンプルコード

Java

public class ClassSample{ public static void methodSample(){ // ローカル変数 int num = 1; } }

1
2
3
4
5
6

public class ClassSample{
public static void methodSample(){
// ローカル変数
int num = 1;
}
}
メソッド内に記述します。
そのメソッドが実行中の間だけ有効となります。
Javaスタックと呼ばれるスレッド固有メモリ領域へ保存される為、スレッドセーフとなります。

1. log4j 1.x と log4j2 の要点比較

2. こんな場面で「log4j2」を選ぶ

3. 導入手順（Maven/Gradle）――最短で“動く”まで

3.1 依存関係を追加

Maven（pom.xml）

Gradle（Kotlin DSL）

3.2 旧実装の衝突を避ける（例：Maven の除外）

3.3 最小構成の設定ファイル（src/main/resources/log4j2.xml）

3.4 SLF4J での利用コード

3.5 ローリングファイル＋JSON（実戦向け）

3.6 非同期化の推奨設定（高スループット向け）

3.7 現場で必須の“相関ID”（MDC/ThreadContext）

3.8 動的なログレベル変更（コード＆設定）

3.9 他フレームワークのログを一本化（任意）

4. 旧 log4j 1.x からの移行チェックリスト

5. 開発・運用の実用Tips

6. まとめ

関連記事

Javaから外部コマンドを実行する基本

1. ファイル送信（utlsend）

2. ファイル受信（utlrecv）

3. ファイル連結（utlconcat）

4. ファイル分割（utlsplit）

運用上の注意点

まとめ

関連記事

GCとは何か

ざっくり構造・最近のGC

主なトリガ

“悪い例 → 良い例”で学ぶメモリ/GC対策

1) 無制限キャッシュ（静的Map地獄）

2) リスナ/コールバック未解除

3) ThreadLocal の放置（プールスレッドに張り付く）

4) System.gc() 乱用

5) ラムダ/内部クラスが外側（巨大オブジェクト）をキャプチャ

6) ループ内の大量一時オブジェクト

7) finalize/Cleaner頼み（遅延・不確実）

8) クラスローダ・アプリ再デプロイ時のリーク

9) 巨大配列・Humongous割当ての長期保持（G1）

10) 無制限のキュー/バッファ

GCログ・計測の始め方（JDK 9+）

実務チェックリスト（配布推奨）

まとめ

関連記事

jdkのダウンロード

jdkのインストール手順

関連記事

Javaでの変数毎のメモリ管理イメージ

インスタンス変数とは

ローカル変数とは

関連記事

「駑馬十駕」を信念に IT系情報を中心に調べた事をコツコツ綴っています。

3.3 最小構成の設定ファイル（`src/main/resources/log4j2.xml`）

　関連記事

1. ファイル送信（`utlsend`）

2. ファイル受信（`utlrecv`）

3. ファイル連結（`utlconcat`）

4. ファイル分割（`utlsplit`）

　関連記事

3) `ThreadLocal` の放置（プールスレッドに張り付く）

4) `System.gc()` 乱用

　関連記事

　関連記事

　関連記事