Как исправишь периодическую перезагрузку сервера из-за OutOfMemoryError

Ответ: Исправление OutOfMemoryError

OutOfMemoryError - серьёзная проблема, требующая систематического подхода. Вот мой алгоритм диагностики и исправления.

Шаг 1: Анализ heap dump

// Собираем heap dump при ошибке
// В JVM параметры добавляем:
// -XX:+HeapDumpOnOutOfMemoryError 
// -XX:HeapDumpPath=/var/logs/heapdump.hprof

// Анализируем dump с помощью:
// 1. Eclipse Memory Analyzer (MAT)
// 2. JProfiler
// 3. YourKit

public class HeapAnalysis {
    // Смотрим:
    // - Какие объекты занимают больше всего памяти
    // - Какие классы повторяются чаще всего
    // - Есть ли утечки памяти (object leaks)
}

Шаг 2: Анализ GC логов

// Включаем детальное логирование GC:
// -Xmx2G                           // Max heap size
// -XX:+PrintGCDetails
// -XX:+PrintGCDateStamps
// -XX:+PrintGCApplicationStoppedTime
// -Xloggc:/var/logs/gc.log

public class GCAnalysis {
    // Анализируем с помощью:
    // - GC Easy (gceasy.io)
    // - GC Viewer
    // - Splunk для production
    
    // Смотрим:
    // - Как часто происходит Full GC
    // - Сколько времени требует GC
    // - Тренд памяти (memory leak?)
}

Шаг 3: Типичные причины и решения

// ПРИЧИНА 1: Memory Leak в приложении
public class MemoryLeakExample {
    private static List<String> cache = new ArrayList<>();  // Растёт бесконечно!
    
    public void processData(String data) {
        cache.add(data);  // Объекты никогда не удаляются
    }
    
    // РЕШЕНИЕ: использовать bounded cache
    private final Map<String, String> cache = 
        new LinkedHashMap<String, String>(16, 0.75f, true) {
            protected boolean removeEldestEntry(Map.Entry eldest) {
                return size() > 1000;  // Максимум 1000 элементов
            }
        };
}

// ПРИЧИНА 2: Утечка внешних ресурсов
public class ResourceLeakExample {
    public void processFile() throws IOException {
        BufferedReader reader = new FileReader("file.txt");  // Забыл закрыть!
        // reader никогда не закрывается, копится memory
    }
    
    // РЕШЕНИЕ: try-with-resources (Java 7+)
    public void processFileFixed() throws IOException {
        try (BufferedReader reader = new BufferedReader(
                new FileReader("file.txt"))) {
            // reader автоматически закроется
        }
    }
}

// ПРИЧИНА 3: Неправильная конфигурация кеша
public class CacheConfigExample {
    // ПЛОХО: Caffeine кеш без максимального размера
    @Bean
    public Cache<String, User> cache() {
        return Caffeine.newBuilder()
            .build();  // Растёт без ограничений!
    }
    
    // ХОРОШО: с ограничениями
    @Bean
    public Cache<String, User> cacheFixed() {
        return Caffeine.newBuilder()
            .maximumSize(10000)         // Максимум элементов
            .expireAfterWrite(10, TimeUnit.MINUTES)  // TTL
            .recordStats()              // Для мониторинга
            .build();
    }
}

// ПРИЧИНА 4: Большие временные объекты
public class LargeObjectExample {
    // ПЛОХО: создание больших массивов в цикле
    public void processBatch(List<Item> items) {
        for (Item item : items) {
            byte[] largeBuffer = new byte[1024 * 1024 * 100];  // 100MB!
            // Используем largeBuffer
        }  // После цикла: 100MB * количество items
    }
    
    // ХОРОШО: переиспользуем buffer
    public void processBatchFixed(List<Item> items) {
        byte[] reusableBuffer = new byte[1024 * 1024];  // 1MB раз
        for (Item item : items) {
            // Переиспользуем reusableBuffer
        }
    }
}

// ПРИЧИНА 5: Неправильный thread pool
public class ThreadPoolExample {
    // ПЛОХО: unbounded queue
    public ExecutorService executor = Executors.newFixedThreadPool(10);
    
    // Если есть спайк: 1000 задач добавляются в очередь
    // Очередь растёт, память кончается
    
    // ХОРОШО: bounded queue
    public ExecutorService executorFixed = new ThreadPoolExecutor(
        10,                           // core threads
        20,                           // max threads
        60, TimeUnit.SECONDS,        // keep alive
        new LinkedBlockingQueue<>(1000),  // Bounded queue!
        new ThreadPoolExecutor.CallerRunsPolicy()  // Rejection policy
    );
}

Шаг 4: Мониторинг в production

// Используем метрики для раннего обнаружения
@Configuration
public class MetricsConfiguration {
    // Через Micrometer / Prometheus
    public void configureMetrics(MeterRegistry registry) {
        // Heap memory usage
        MeterBinder.of(
            () -> (double) Runtime.getRuntime().totalMemory()
        ).bindTo(registry);
        
        // GC pause time
        new ClassLoaderMetrics().bindTo(registry);
    }
}

// Алерты:
public class Alerts {
    // Если heap usage > 80% -> alert
    // Если Full GC happening > 5 раз в минуту -> alert
    // Если GC pause time > 1 секунда -> alert
}

Пошаговый процесс исправления

public class FixingProcess {
    // 1. Собираю информацию
    public void step1_gather() {
        // Heap dumps
        // GC logs
        // Application logs (errors, warnings)
        // Metrics (Prometheus/Grafana)
        // Размер базы, файлов, кешей
    }
    
    // 2. Анализирую с командой
    public void step2_analyze() {
        // Обсуждение вероятных причин
        // Приоритизация по вероятности
        // Гипотезы для проверки
    }
    
    // 3. Репликирую локально
    public void step3_reproduce() {
        // Load testing
        // Stress testing
        // Симуляция production условий
    }
    
    // 4. Исправляю и тестирую
    public void step4_fix() {
        // Code fix
        // Configuration tuning
        // JVM параметры
        // Verification
    }
    
    // 5. Мониторю
    public void step5_monitor() {
        // Развертывание в staging
        // Load test
        // Медленное разворачивание в production
        // Постоянный мониторинг метрик
    }
}

Примеры JVM настроек при OutOfMemory

# Рекомендации для типичного приложения
java -Xms2G                          # Initial heap
     -Xmx4G                          # Max heap
     -XX:+UseG1GC                    # G1 garbage collector (лучше для большие heap)
     -XX:MaxGCPauseMillis=200        # Максимальная пауза GC
     -XX:+ParallelRefProcEnabled     # Параллельная обработка references
     -XX:+UnlockDiagnosticVMOptions
     -XX:+PrintFlagsFinal            # Для проверки параметров
     -XX:+HeapDumpOnOutOfMemoryError
     -XX:HeapDumpPath=/var/logs/
     MyApplication

Долгосрочные решения

// 1. Code review и static analysis
public class Prevention {
    // SonarQube - обнаружение memory leaks
    // SpotBugs - потенциальные проблемы
    // Архитектурный review
}

// 2. Автоматизированное тестирование
public class AutomatedTesting {
    // Load tests - регулярно проверяют на memory leaks
    // Stress tests - поведение при нагрузке
    // Memory profiling в CI/CD
}

// 3. Культура качества
public class CultureImprovement {
    // Обучение команды
    // Shared learnings
    // Post-mortems при incidents
}

Вывод: OutOfMemoryError требует систематического подхода - от анализа heap dump и GC логов до репликации проблемы и долгосрочного мониторинга. Важны как техническое решение, так и организационные меры (code review, тестирование, мониторинг) для предотвращения регрессии.