Советы по производительности и оптимизации Java

Java достаточно быстра почти для всего, но медленный код всё равно случается — как правило, из-за лишней работы, избыточного выделения памяти или неправильного выбора структуры данных. Важнейший совет по производительности — вовсе не трюк: измеряйте прежде, чем что-либо менять. В этой главе рассказывается, как честно проводить измерения, какие оптимизации чаще всего окупаются (построение строк, выбор структур данных, избегание лишнего выделения памяти), а также о подводных камнях, из-за которых наивный «быстрый» код на самом деле оказывается медленным.

Сначала измеряйте, потом оптимизируйте

Догадки о производительности — верный способ потратить часы на ускорение кода, который никогда не был медленным. Профилируйте реальную нагрузку, найдите горячий путь (тот небольшой участок кода, где тратится большая часть времени), и только после этого оптимизируйте его. Для быстрых экспериментов System.nanoTime() даёт разницу по «настенным часам»; для серьёзных бенчмарков используйте инструмент вроде JMH (Java Microbenchmark Harness), который прогревает JIT и учитывает погрешности измерений.

long start = System.nanoTime();
doWork();
long elapsedMs = (System.nanoTime() - start) / 1_000_000;
System.out.println("Took " + elapsedMs + " ms");

К этому прилагаются два правила. Во-первых, избегайте преждевременной оптимизации — понятный код, который достаточно быстр, лучше хитрого кода, который трудно читать. Во-вторых, JIT-компилятор JVM оптимизирует горячий код во время выполнения, поэтому метод выходит на полную скорость лишь после многократного вызова; одиночный замер мало о чём говорит.

Строим строки с помощью StringBuilder

Поскольку строки неизменяемы, s += x внутри цикла создаёт новую строку и копирует все предыдущие символы на каждой итерации — это работа O(n²). StringBuilder хранит растущий буфер и дополняет его на месте, превращая ту же задачу в O(n).

// Slow: a new String allocated every iteration
String csv = "";
for (String field : fields) {
    csv += field + ",";
}

// Fast: one buffer, appended in place
StringBuilder sb = new StringBuilder();
for (String field : fields) {
    sb.append(field).append(',');
}
String csv2 = sb.toString();

Одиночная конкатенация a + b + c вне цикла не проблема — компилятор уже преобразует её в один StringBuilder (смотрите конкатенацию строк, чтобы понять, что делает компилятор). Проблема — конкатенация внутри цикла, где каждый проход добавляет ещё одну полную копию.

Выбирайте правильную структуру данных

Наибольший выигрыш обычно даёт алгоритмический выбор, а не микрооптимизации. Поиск значения в ArrayList перебирает все элементы (O(n)); HashMap или HashSet делают это за примерно постоянное время (O(1)). Выбирайте коллекцию, которая соответствует тому, как вы на самом деле обращаетесь к данным.

Потребность	Используйте	Стоимость поиска
Доступ по индексу, добавление в конец	`ArrayList`	O(1) по индексу, O(n) по значению
Поиск по ключу/значению	`HashMap`	O(1) в среднем
Проверка вхождения, без дубликатов	`HashSet`	O(1) в среднем
Отсортированные ключи	`TreeMap`	O(log n)
Частые вставки/удаления с концов	`ArrayDeque`	O(1) на концах

Если вы знаете финальный размер, передайте его в конструктор: new ArrayList<>(10_000) или new HashMap<>(capacity). Это позволяет избежать повторного перераспределения памяти и копирования при росте коллекции.

Избегайте лишнего создания объектов

Каждый выделенный объект впоследствии нужно собрать, а сборка мусора не бесплатна. Переиспользуйте неизменяемые значения, предпочитайте примитивы их упакованным обёрткам в горячих циклах и не создавайте объекты, которые тут же выбрасываются.

// Autoboxing: every += boxes a new Integer
Long total = 0L;
for (int i = 0; i < n; i++) total += i;   // slow, allocates boxes

// Primitive: no allocation at all
long sum = 0L;
for (int i = 0; i < n; i++) sum += i;     // fast

Другие простые выигрыши: кешируйте скомпилированные объекты Pattern вместо вызова String.matches() в цикле, переиспользуйте DateTimeFormatter (он потокобезопасен и неизменяем), а в самых горячих внутренних циклах, где важно выделение памяти, предпочитайте расширенный for потокам.

java— editable, runs on the server

import java.util.*;

public class PerfDemo {
    public static void main(String[] args) {
        int n = 100_000;

// 1. String concatenation in a loop vs StringBuilder
        long t0 = System.nanoTime();
        String s = "";
        for (int i = 0; i < 2_000; i++) {
            s += i;
        }
        long concatNs = System.nanoTime() - t0;

long t1 = System.nanoTime();
        StringBuilder sb = new StringBuilder();
        for (int i = 0; i < 2_000; i++) {
            sb.append(i);
        }
        String built = sb.toString();
        long builderNs = System.nanoTime() - t1;

System.out.println("Same result? " + s.equals(built));
        System.out.println("String += ratio vs StringBuilder: ~"
                + Math.max(1, concatNs / Math.max(1, builderNs)) + "x slower");

// 2. Pre-sizing a collection avoids repeated resizing
        long t2 = System.nanoTime();
        List<Integer> grow = new ArrayList<>();
        for (int i = 0; i < n; i++) grow.add(i);
        long growNs = System.nanoTime() - t2;

long t3 = System.nanoTime();
        List<Integer> sized = new ArrayList<>(n);
        for (int i = 0; i < n; i++) sized.add(i);
        long sizedNs = System.nanoTime() - t3;

System.out.println("Both lists size " + n + ": "
                + (grow.size() == sized.size()));
        System.out.println("Pre-sized faster? " + (sizedNs <= growNs));

// 3. Right data structure: HashMap O(1) vs List scan O(n)
        Map<Integer, Integer> map = new HashMap<>(n * 2);
        for (int i = 0; i < n; i++) map.put(i, i * 2);

long t4 = System.nanoTime();
        int hits = 0;
        for (int q = 0; q < 50_000; q++) {
            if (map.containsKey(q)) hits++;
        }
        long mapNs = System.nanoTime() - t4;
        System.out.println("Map lookups found: " + hits
                + " in " + (mapNs / 1_000_000) + " ms");

// 4. Autoboxing cost: int[] sum vs Integer boxing
        long sum = 0;
        for (int i = 0; i < n; i++) sum += i;
        System.out.println("Primitive sum: " + sum);

System.out.println("Lesson: measure, then pick the right tool.");
    }
}

Что можно вынести из запуска:

Same result? true доказывает, что StringBuilder производит ровно ту же строку, что и +=, поэтому замена влияет только на скорость, но не на корректность.
Напечатанное соотношение «x slower» показывает, что конкатенация в цикле обходится во много раз дороже добавления в буфер, поскольку каждый += копирует всю строку целиком.
Both lists size 100000: true подтверждает, что ArrayList с предварительно заданным размером в итоге идентичен тому, что рос динамически — подсказка конструктору влияет на выделение памяти, а не на содержимое.
Pre-sized faster? true показывает, что указание ArrayList ёмкости заранее позволяет избежать повторных шагов изменения размера и копирования.
Map lookups found: 50000 in ... ms демонстрирует, что 50 000 обращений к HashMap завершаются примерно за миллисекунду — вот цена выбора доступа O(1) вместо сканирования списка O(n).

Распространённые ловушки

Несколько ошибок превращают «очевидно быстрый» код в противоположность:

Доверие единственному замеру. JIT ещё не прогрелся, а ОС могла переключиться на другую задачу прямо в момент измерения. Повторите работу тысячи раз или используйте JMH, прежде чем доверять числу.
Микрооптимизация холодного кода. Метод, запускаемый один раз при старте, ничего не выиграет от более компактного цикла. Тратьте усилия только на горячий путь, на который указывает профайлер.
Построение строк через + в цикле. Самое распространённое устранимое замедление — используйте StringBuilder всякий раз, когда конкатенируете строки внутри цикла.
Скрытый автобоксинг. List<Integer>, Map<Integer, Integer> или случайный аккумулятор типа Long упаковывает каждое значение. В горячем числовом цикле предпочитайте примитивы и массивы примитивов.
Оптимизация до того, как код работает. Сначала правильность, потом скорость. Понятный код, который можно профилировать, лучше хитрого кода, о котором невозможно рассуждать.

Итоги

Измеряйте прежде, чем что-либо менять — профилируйте реальную нагрузку и оптимизируйте только горячий путь.
Стройте строки с помощью StringBuilder, а не +=, внутри циклов.
Подбирайте коллекцию под паттерн доступа: HashMap/HashSet для поиска, ArrayList для индексного доступа; задавайте размер заранее, если количество элементов известно.
Избегайте лишнего выделения памяти: предпочитайте примитивы, переиспользуйте неизменяемые объекты и помните, что каждый объект добавляет работу сборщику мусора.

Практика

Почему использование '+=' для построения String внутри цикла медленнее, чем StringBuilder?

Поскольку String неизменяема, каждый += выделяет новую String и копирует все предыдущие символы, делая цикл O(n в квадрате)Потому что StringBuilder выполняется в отдельном потоке, который JVM планирует первымПотому что оператор += не поддерживается для String и прибегает к рефлексииПотому что конкатенация строк всегда запускает полную сборку мусора на каждой итерации