Где может теряться производительность?

# Где может теряться производительность в Java приложении

1. Память и сборка мусора (GC)

Проблема: Частые GC паузы

// ❌ ПЛОХО: частое создание объектов в цикле
public void processData(List<String> items) {
    for (String item : items) {
        // Каждый цикл создаёт новые объекты
        String trimmed = item.trim();           // new String
        String[] parts = trimmed.split(",");   // new String[] 
        String result = parts[0] + parts[1];    // new String
        
        // GC должен их все удалить
        System.out.println(result);
    }
    // При 1M итераций это ОГРОМНЫЙ GC overhead
}

// ✅ ХОРОШО: переиспользование объектов
private StringBuilder sb = new StringBuilder();
private static final String COMMA = ",";

public void processData(List<String> items) {
    for (String item : items) {
        sb.setLength(0);
        // Переиспользуем StringBuilder
        sb.append(item.trim());
        
        int commaIdx = sb.indexOf(COMMA);
        if (commaIdx > 0) {
            System.out.println(sb.substring(0, commaIdx));
        }
    }
}

Диагностика

# Смотреть GC паузы
java -XX:+PrintGCDetails -XX:+PrintGCDateStamps application.jar

# JMH benchmark
@Fork(value = 3)
@Measurement(iterations = 10)
public class PerformanceTest {
    @Benchmark
    public void testAlgorithm() { ... }
}

2. Многопоточность и синхронизация

Проблема: Contention (конкуренция)

// ❌ ПЛОХО: синхронизированный счётчик
public class Counter {
    private int count = 0;
    
    public synchronized void increment() {
        count++;  // Все потоки ждут друг друга!
    }
}
// При 1000 потоков: 999 ждут, 1 работает

// ✅ ХОРОШО: AtomicInteger
public class Counter {
    private AtomicInteger count = new AtomicInteger(0);
    
    public void increment() {
        count.incrementAndGet();  // Lock-free (CAS операция)
    }
}

// ✅ ЕЩЁ ЛУЧШЕ: LongAdder для высокой нагрузки
private LongAdder count = new LongAdder();

public void increment() {
    count.increment();  // Разделённая память между потоками
}

Проблема: Deadlock

// ❌ ОПАСНО
Object lock1 = new Object();
Object lock2 = new Object();

Thread t1 = new Thread(() -> {
    synchronized(lock1) {
        sleep(100);
        synchronized(lock2) { }  // Может заблокироваться
    }
});

Thread t2 = new Thread(() -> {
    synchronized(lock2) {
        sleep(100);
        synchronized(lock1) { }  // Может заблокироваться
    }
});
// DEADLOCK!

// ✅ ПРАВИЛЬНО: всегда одинаковый порядок
synchronized(lock1) {
    synchronized(lock2) { }
}

3. I/O операции

Проблема: Блокирующие операции

// ❌ ПЛОХО: синхронный HTTP запрос
String data = httpClient.get(url);  // Поток ждёт 100мс
// Если 1000 потоков: 1000 * 100мс = теряем время

// ✅ ХОРОШО: асинхронный
CompletableFuture<String> future = httpClient.getAsync(url);
future.thenAccept(data -> {
    // Обработка, когда данные придут
});

// ✅ ЛУЧШЕ ВСЕГО: Reactive
mono.flatMap(data -> processDataAsync(data))
    .subscribe(result -> sendResponse(result));

Проблема: N+1 запросы

// ❌ ПЛОХО
List<User> users = userRepository.findAll();
for (User user : users) {  // 100 пользователей
    List<Order> orders = orderRepository.findByUserId(user.getId());
    // 1 + 100 = 101 запрос в БД!
}

// ✅ ХОРОШО: JOIN
@Query("SELECT u FROM User u JOIN FETCH u.orders")
List<User> users = userRepository.findAllWithOrders();
// 1 запрос в БД

// ✅ ИЛИ: Batch
List<Order> allOrders = orderRepository.findByUserIdIn(userIds);
Map<Long, List<Order>> grouped = allOrders.stream()
    .collect(groupingBy(Order::getUserId));
// 2 запроса: один за user, один за orders

4. Сетевые операции

Проблема: Сетевая задержка

// ❌ ПЛОХО: последовательные вызовы
User user = fetchUser(id);         // 50мс
Order order = fetchOrder(userId);  // 50мс
Payment payment = fetchPayment(orderId); // 50мс
// Итого: 150мс

// ✅ ХОРОШО: параллельные вызовы
CompletableFuture<User> userFuture = fetchUserAsync(id);
CompletableFuture<Order> orderFuture = fetchOrderAsync(userId);
CompletableFuture<Payment> paymentFuture = fetchPaymentAsync(orderId);

CompletableFuture.allOf(userFuture, orderFuture, paymentFuture).join();
// Итого: 50мс (максимум из трёх)

5. Алгоритмы и структуры данных

Проблема: O(n²) вместо O(n)

// ❌ ПЛОХО: линейный поиск в цикле
for (String name : names) {           // n элементов
    if (blacklist.contains(name)) {   // O(n) поиск в List
        // ...
    }
}
// Сложность: O(n²)

// ✅ ХОРОШО: HashSet
Set<String> blacklist = new HashSet<>(blacklistList);
for (String name : names) {
    if (blacklist.contains(name)) {   // O(1) поиск
        // ...
    }
}
// Сложность: O(n)

// Пример: 1000 имён
// O(n²): 1000 * 1000 = 1,000,000 операций
// O(n): 1000 операций = 1000x быстрее!

Проблема: Неправильная сортировка

// ❌ ПЛОХО: создание нового List каждый раз
List<User> sorted = users.stream()
    .sorted(Comparator.comparing(User::getName))
    .collect(toList());  // O(n log n) каждый раз

// ✅ ХОРОШО: кэшировать
private List<User> cachedSorted = null;

public List<User> getSorted() {
    if (cachedSorted == null) {
        cachedSorted = users.stream()
            .sorted(Comparator.comparing(User::getName))
            .collect(toList());
    }
    return cachedSorted;
}

6. Кэширование

Проблема: Отсутствие кэша

// ❌ ПЛОХО: вычисляем каждый раз
public BigDecimal computeTax(BigDecimal amount) {
    // Сложные вычисления
    return amount.multiply(TAX_RATE);
}
// Если вызывается 1M раз — тратим время впустую

// ✅ ХОРОШО: кэшировать результаты
private Map<BigDecimal, BigDecimal> taxCache = new ConcurrentHashMap<>();

public BigDecimal computeTax(BigDecimal amount) {
    return taxCache.computeIfAbsent(amount, 
        key -> key.multiply(TAX_RATE));
}

// ✅ ИЛИ: Guava Cache
private LoadingCache<BigDecimal, BigDecimal> taxCache = 
    CacheBuilder.newBuilder()
        .expireAfterWrite(1, TimeUnit.HOURS)
        .build(new CacheLoader<BigDecimal, BigDecimal>() {
            public BigDecimal load(BigDecimal amount) {
                return amount.multiply(TAX_RATE);
            }
        });

7. String операции

Проблема: Конкатенация в цикле

// ❌ ПЛОХО
String result = "";
for (int i = 0; i < 10000; i++) {
    result += "item" + i + ",";  // Каждый раз new String!
}
// 10000 новых объектов → огромный GC

// ✅ ХОРОШО
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 10000; i++) {
    sb.append("item").append(i).append(",");
}
String result = sb.toString();  // 1 новый объект

8. Рефлексия

Проблема: Частое использование reflection

// ❌ ПЛОХО
for (String item : items) {
    Method method = MyClass.class.getMethod("process");
    method.invoke(instance);  // Reflection overhead
}

// ✅ ХОРОШО: кэшировать Method
private static final Method PROCESS_METHOD;
static {
    try {
        PROCESS_METHOD = MyClass.class.getMethod("process");
    } catch (NoSuchMethodException e) {
        throw new ExceptionInInitializerError(e);
    }
}

for (String item : items) {
    PROCESS_METHOD.invoke(instance);
}

9. Сборка данных (Serialization)

Проблема: Неправильная сериализация

// ❌ ПЛОХО: JSON каждый раз
ObjectMapper mapper = new ObjectMapper();
for (User user : users) {
    String json = mapper.writeValueAsString(user);
    // Новый ObjectMapper или одна экземпляра?
}

// ✅ ХОРОШО: переиспользовать mapper
private static final ObjectMapper mapper = new ObjectMapper();
for (User user : users) {
    String json = mapper.writeValueAsString(user);
}

10. JVM настройки

Проблема: Неправильные JVM флаги

# ❌ ПЛОХО: мало памяти
java -Xmx256m application.jar
# Частые GC паузы

# ✅ ХОРОШО: правильный баланс
java -Xmx4g -Xms4g -XX:+UseG1GC application.jar
# Нет резкого расширения памяти, быстрый GC

# ✅ ДЛЯ НИЗКИХ ЗАДЕРЖЕК
java -XX:+UseZGC -XX:ZCollectionInterval=120 application.jar
# ZGC даёт паузы < 1ms

Инструменты для диагностики

1. JProfiler — визуальный профайлер
2. YourKit — мониторинг в production
3. Java Flight Recorder — встроенный профайлер
4. Async Profiler — с минимальным overhead
5. JMH — микро-бенчмарки

Чеклист оптимизации

• Профайлить перед оптимизацией (не гадать!)
• Отслеживать GC паузы
• Избегать contention при многопоточности
• Минимизировать I/O операции
• Выбирать правильные структуры данных
• Кэшировать часто используемые результаты
• Использовать асинхронность для IO
• Настроить JVM параметры

Заключение

Производительность теряется в сочетании факторов:

• 🔴 40%: Неправильные алгоритмы (O(n²) вместо O(n))
• 🟠 30%: GC паузы и управление памятью
• 🟡 20%: Многопоточность и contention
• 🟢 10%: Сетевые и I/O операции

Ключ: Профайлировать реальный код, не гадать!