Может ли JVM оставить артефакты для анализа после падения приложения?

Question

claude-haiku-4.5 · Accepted Answer

## Ответ

Да, JVM может оставлять различные артефакты (файлы и дампы) для анализа после падения приложения. Это критично для отладки production проблем. Рассмотрю все типы артефактов и способы их получения.

### 1. Heap Dump — дамп памяти

Сохраняет состояние памяти при падении приложения.

**Автоматический heap dump при OutOfMemoryError:**

```bash
java -XX:+HeapDumpOnOutOfMemoryError \
     -XX:HeapDumpPath=/var/dumps/ \
     -jar myapp.jar
```

При OOM создаётся файл вроде `java_pid12345.hprof`:

```bash
ls -la /var/dumps/
java_pid12345.hprof  # Анализировать в Eclipse MAT или jhat
```

**Анализ heap dump:**

```bash
# Используя jhat (Java Heap Analysis Tool)
jhat java_pid12345.hprof
# Откроется веб-интерфейс на localhost:7000

# Или Eclipse Memory Analyzer
# Скачиваете MAT и загружаете файл через GUI
```

### 2. Thread Dump — дамп потоков

Показывает стек вызовов всех потоков в момент падения.

**Получение thread dump при падении:**

```bash
java -XX:+UnlockDiagnosticVMOptions \
     -XX:+PrintDeadlockAuto \
     -XX:+PrintDeadlocks \
     -XX:PrintDeadlocksFile=/var/dumps/deadlocks.txt \
     -jar myapp.jar
```

**Вручную получить thread dump:**

```bash
# Найти PID процесса
jps
# 12345 MyApplication

# Получить thread dump
jstack 12345 > thread_dump_$(date +%s).txt

# Или через kill с сигналом SIGQUIT
kill -3 12345
# Дамп выведется в консоль
```

### 3. Core Dump — полный дамп памяти ОС

**Включение core dump:**

```bash
# Linux
ulimit -c unlimited  # Разрешить core dumps

java -XX:+CreateCoredumpOnCrash \
     -jar myapp.jar

# Если приложение упадёт, будет создан core файл
ls -la core*  # core.12345
```

**Анализ core dump с помощью gdb:**

```bash
# Требует символов Java
gdb java core.12345

# Внутри gdb
(gdb) bt    # backtrace
(gdb) info registers
(gdb) info threads
```

### 4. GC Logs — логи сборки мусора

**Включение GC логирования:**

```bash
java -Xmx2G \
     -XX:+PrintGCDetails \
     -XX:+PrintGCDateStamps \
     -XX:+PrintGCTimeStamps \
     -Xloggc:/var/logs/gc_%t.log \
     -XX:+UseGCLogFileRotation \
     -XX:NumberOfGCLogFiles=5 \
     -XX:GCLogFileSize=100M \
     -jar myapp.jar
```

**Современный способ (Java 9+):**

```bash
java -Xmx2G \
     -Xlog:gc*:file=/var/logs/gc.log:time,level,tags:filecount=5,filesize=100m \
     -jar myapp.jar
```

**Анализ GC логов:**

```bash
# Просмотр
tail -f /var/logs/gc.log

# Анализ с GCeasy.io (онлайн сервис)
# Или инструментами вроде GCViewer
```

### 5. Crash Dump — дамп при нативном краше

Когда падает native код (JNI):

```bash
java -XX:+CrashOnOutOfMemoryError \
     -XX:OnOutOfMemoryError="bash -c 'kill -3 %p'" \
     -jar myapp.jar
```

**Для анализа Linux crash dumps:**

```bash
# Сохранилась информация в /var/log/kern.log
tail -f /var/log/kern.log

# Segmentation fault? Ищите в messages
dmesg | tail -20
```

### 6. Log Files — файлы логов приложения

**Правильная конфигурация логирования:**

```bash
java -Dlogging.level.root=INFO \
     -Dlogging.file.name=/var/logs/app.log \
     -Dlogging.file.max-size=100MB \
     -Dlogging.file.max-history=30 \
     -jar myapp.jar
```

**Структурированное логирование для анализа:**

```java
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class Application {
    private static final Logger log = LoggerFactory.getLogger(Application.class);
    
    public static void main(String[] args) {
        try {
            log.info("Application started");
            // ...
        } catch (Exception e) {
            log.error("Critical error occurred", e);
            System.exit(1);
        }
    }
}
```

### 7. Hs_err_pid файлы — отчёты об ошибках JVM

Автоматически создаются при native crashes:

```bash
ls -la hs_err_pid*.log
# hs_err_pid12345.log

# Файл содержит:
# - Stack trace
# - Информацию о потоках
# - Memory информацию
# - Версию JVM
# - Системную информацию
```

**Пример hs_err файла:**

```
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f3a4c5d6e01, pid=12345, tid=0x00007f3a4f2a2700
#
# JRE version: OpenJDK Runtime Environment (17.0.1+12)
# Java VM: OpenJDK 64-Bit Server VM (17.0.1+12, mixed mode, tiered, compressed oops)
...
```

### 8. Файлы дампов — полная конфигурация

**Полный набор параметров для production:**

```bash
java -server \
     # Heap dumps
     -XX:+HeapDumpOnOutOfMemoryError \
     -XX:HeapDumpPath=/var/dumps/heap \
     -XX:+HeapDumpOnExit \
     \
     # Thread deadlock detection
     -XX:+PrintDeadlocks \
     -XX:+PrintDeadlocksFile=/var/dumps/deadlocks.txt \
     \
     # GC logging
     -Xlog:gc*:file=/var/logs/gc_%t.log:time,level,tags:filecount=5,filesize=100m \
     \
     # Core dumps
     -XX:+CreateCoredumpOnCrash \
     \
     # JVM crash logs
     -XX:ErrorFile=/var/dumps/hs_err_pid_%p.log \
     \
     -jar myapp.jar
```

### 9. Сбор артефактов с production сервера

**Скрипт для сбора всех артефактов:**

```bash
#!/bin/bash

COLLECT_DIR="/tmp/artifacts_$(date +%s)"
mkdir -p $COLLECT_DIR

echo "Collecting artifacts..."

# Heap dumps
cp -r /var/dumps/heap* $COLLECT_DIR/ 2>/dev/null

# GC logs
cp /var/logs/gc_*.log $COLLECT_DIR/ 2>/dev/null

# Application logs
cp /var/logs/app.log* $COLLECT_DIR/ 2>/dev/null

# JVM crash logs
cp hs_err_pid_*.log $COLLECT_DIR/ 2>/dev/null

# Thread dumps
jps | awk '{print $1}' | xargs -I {} jstack {} > $COLLECT_DIR/thread_dump_{}.txt 2>/dev/null

# System info
uname -a > $COLLECT_DIR/system_info.txt
free -h >> $COLLECT_DIR/system_info.txt

# Pack
tar -czf artifacts_$(date +%s).tar.gz -C /tmp $COLLECT_DIR
echo "Artifacts saved to: artifacts_*.tar.gz"
```

### 10. Анализ артефактов

**Heap dump анализ (Eclipse MAT):**

```bash
# Скачать MAT
wget https://www.eclipse.org/downloads/download.php?file=technology/mat/

# Откроить через GUI и загрузить файл
# Смотреть:
# - Largest objects
# - Leaked objects
# - Top consumers
```

**GC logs анализ:**

```bash
# Использовать GCeasy (онлайн)
https://gceasy.io/

# Или локально с GCViewer
java -jar gcviewer.jar gc.log
```

### 11. Стандартные места для дампов

```bash
# Linux
/var/dumps/              # Heap dumps
/var/logs/               # GC и app logs
/root/                   # hs_err файлы (текущая директория)
/var/crash/              # Core dumps

# Или указать явно при запуске
java -XX:HeapDumpPath=/custom/path \
     -Xloggc:/custom/path/gc.log \
     -jar myapp.jar
```

### Вывод

Да, JVM оставляет следующие артефакты:

1. **Heap Dump** (.hprof) — для анализа утечек памяти
2. **Thread Dump** (.txt) — для анализа deadlocks
3. **GC Logs** (gc.log) — для анализа производительности
4. **Core Dump** (core.*) — для анализа native crashes
5. **hs_err файлы** (hs_err_pid.log) — для анализа критических ошибок
6. **Application logs** — для анализа логики ошибок

Для production приложений обязательно включите все эти параметры и регулярно проверяйте артефакты.

Может ли JVM оставить артефакты для анализа после падения приложения?

Комментарии (1)

Ответ

1. Heap Dump — дамп памяти

2. Thread Dump — дамп потоков

3. Core Dump — полный дамп памяти ОС

4. GC Logs — логи сборки мусора

5. Crash Dump — дамп при нативном краше

6. Log Files — файлы логов приложения

7. Hs_err_pid файлы — отчёты об ошибках JVM

8. Файлы дампов — полная конфигурация

9. Сбор артефактов с production сервера

10. Анализ артефактов

11. Стандартные места для дампов

Вывод