Как настроить сборщика мусора

# Настройка сборщика мусора (GC) в Java

Основные концепции

Garbage Collector (GC) управляет памятью приложения, автоматически удаляя недостижимые объекты. Выбор GC влияет на производительность, latency и throughput.

1. Основные типы GC

Serial GC (простейший)

Для однопроцессорных систем или небольших приложений.

java -XX:+UseSerialGC -Xmx1024m MyApplication

Характеристики:

• Один поток для GC
• Останавливает приложение (Stop the World)
• Минимальные накладные расходы
• Низкая пропускная способность

Parallel GC (Z-GC для высоконагруженных систем)

Использует несколько потоков для сборки мусора.

java -XX:+UseParallelGC -XX:ParallelGCThreads=8 -Xmx4g MyApplication

Параметры:

• ParallelGCThreads: количество потоков GC
• MaxGCPauseMillis: целевое время паузы
• GCTimeRatio: целевое соотношение времени GC к времени приложения

CMS GC (Concurrent Mark Sweep) - устарел в Java 14+

Попытается минимизировать паузы за счет concurrent работы.

java -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Xmx4g MyApplication

G1GC (Garbage First) - рекомендуется для heap > 4GB

Разделяет heap на регионы и собирает сначала те, которые содержат много мусора.

java -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=200 \
  -XX:InitiatingHeapOccupancyPercent=35 \
  -Xmx8g \
  MyApplication

Параметры G1GC:

• MaxGCPauseMillis: максимальное целевое время паузы (200ms дефолт)
• InitiatingHeapOccupancyPercent: % заполнения heap для начала concurrent GC
• G1NewSizePercent: минимальный % для young generation
• G1MaxNewSizePercent: максимальный % для young generation

ZGC (Z Garbage Collector) - Java 15+, для microsecond pauses

Для приложений, требующих минимальной latency (< 10ms pauses).

java -XX:+UnlockExperimentalVMOptions \
  -XX:+UseZGC \
  -XX:ZUncommitDelay=30 \
  -Xmx16g \
  MyApplication

Характеристики:

• Concurrent mark, relocate, reference processing
• Паузы < 10ms независимо от heap размера
• Требует больше CPU и памяти
• Идеален для микросервисов

2. Настройка памяти

# Базовые параметры памяти
java -Xms4g -Xmx8g MyApplication
# -Xms: начальный heap размер
# -Xmx: максимальный heap размер

# Young Generation (для Short-lived объектов)
java -Xms4g -Xmx8g -XX:NewRatio=3 MyApplication
# NewRatio=3 означает Young:Old = 1:3

# Или явно установить размер
java -Xms4g -Xmx8g -XX:NewSize=1g -XX:MaxNewSize=2g MyApplication

# Метаспейс (для class metadata)
java -Xms4g -Xmx8g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m MyApplication

3. Мониторинг GC

# Логирование GC
java -Xms4g -Xmx8g \
  -XX:+PrintGCDetails \
  -XX:+PrintGCDateStamps \
  -XX:+PrintGCApplicationStoppedTime \
  -XX:+PrintTenuringDistribution \
  -Xloggc:gc.log \
  MyApplication

# Java 9+ (рекомендуется)
java -Xms4g -Xmx8g \
  -Xlog:gc*:file=gc.log:time,level,tags \
  -Xlog:gc+ergo*=trace:file=gc.log:time,level,tags \
  MyApplication

4. Детальный пример конфигурации для Production

java -server \
  -Xms4g -Xmx8g \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=200 \
  -XX:InitiatingHeapOccupancyPercent=35 \
  -XX:G1ReservePercent=10 \
  -XX:+ParallelRefProcEnabled \
  -XX:+UnlockDiagnosticVMOptions \
  -XX:G1SummarizeRSetStatsPeriod=1 \
  -XX:+PrintFlagsFinal \
  -Xlog:gc*:file=gc.log:time,level,tags \
  -Dcom.sun.management.jmxremote.port=9010 \
  -Dcom.sun.management.jmxremote.authenticate=false \
  -Dcom.sun.management.jmxremote.ssl=false \
  com.example.Application

5. Spring Boot application.yml конфигурация

spring:
  application:
    name: my-service

server:
  port: 8080

# Запуск приложения:
# java -Xms2g -Xmx4g -XX:+UseG1GC -jar app.jar --spring.profiles.active=production

# application-production.properties
server.tomcat.threads.max=200
server.tomcat.threads.min-spare=10
spring.datasource.hikari.maximum-pool-size=20
spring.jpa.properties.hibernate.jdbc.batch_size=20

6. JVM опции через Docker/Kubernetes

FROM openjdk:17-jdk-slim
WORKDIR /app
COPY app.jar app.jar

ENV JAVA_OPTS="-Xms512m -Xmx2g -XX:+UseG1GC -XX:MaxGCPauseMillis=200"

CMD java ${JAVA_OPTS} -jar app.jar

# Kubernetes deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-service
spec:
  template:
    spec:
      containers:
      - name: app
        image: my-service:latest
        env:
        - name: JAVA_OPTS
          value: "-Xms1g -Xmx2g -XX:+UseG1GC -XX:MaxGCPauseMillis=200"
        resources:
          requests:
            memory: "2.5Gi"
            cpu: "1000m"
          limits:
            memory: "3Gi"
            cpu: "2000m"

7. Анализ GC логов

import com.sun.management.GarbageCollectionNotificationInfo;
import java.lang.management.GarbageCollectorMXBean;
import java.lang.management.ManagementFactory;
import javax.management.Notification;
import javax.management.NotificationListener;

public class GCMonitor {
    public static void main(String[] args) {
        for (GarbageCollectorMXBean gcBean : ManagementFactory.getGarbageCollectorMXBeans()) {
            System.out.println("GC: " + gcBean.getName());
            System.out.println("  Collection count: " + gcBean.getCollectionCount());
            System.out.println("  Collection time: " + gcBean.getCollectionTime() + "ms");
        }
    }
}

8. Выбор GC в зависимости от сценария

Best Practices

1. Установи Xms = Xmx - избегает dynamic heap resizing
2. Используй G1GC для heap > 4GB - лучше балансирует latency и throughput
3. Мониторь heap использование - используй JVisualVM или Prometheus
4. Профилируй приложение - находи memory leaks с JProfiler
5. Настраивай MaxGCPauseMillis осторожно - слишком низкое = частые GC
6. Тестируй под реальной нагрузкой - GC поведение зависит от паттернов allocation
7. Используй CMS только если очень низкая latency критична - сложнее отлаживать
8. Логируй GC подробно в production - помогает диагностировать проблемы