Топ 10 простых оптимизаций производительности в Java

Было много ажиотажа по поводу модного слова « масштабирование сети », и люди проходят через многие этапы реорганизации архитектуры своих приложений, чтобы заставить свои системы «масштабироваться».

Но что  такое  масштабирование, и как мы можем быть уверены, что  можем  масштабировать?

Различные аспекты масштабирования

Упомянутый выше обман главным образом связан с масштабированием  нагрузки , то есть для того, чтобы система, которая работает на 1 пользователя, также работала хорошо для 10 пользователей, или 100 пользователей, или миллионов. В идеале ваша система должна быть как можно более «не имеющей состояния», чтобы оставшиеся несколько состояний могли быть перенесены и преобразованы на любом процессоре в вашей сети. Когда загрузка является вашей проблемой, задержка, вероятно, нет, поэтому все в порядке, если отдельные запросы занимают 50-100 мс. Это часто также называют  масштабированием

Абсолютно другой аспект масштабирования связан с масштабированием  производительности , т. Е. Чтобы убедиться, что алгоритм, который работает для 1 фрагмента информации, также будет хорошо работать для 10 частей, или 100 частей, или миллионов. Реализуется ли этот тип масштабирования лучше всего в  Big O Notation . Задержка является убийцей при масштабировании производительности. Вы хотите сделать все возможное, чтобы сохранить все расчеты на одной машине. Это часто также называют  расширением

Если бы было что-то вроде бесплатного ланча ( нет ), мы могли бы бесконечно комбинировать масштабирование. Во всяком случае, сегодня мы рассмотрим несколько очень простых способов улучшить ситуацию с точки зрения производительности.

Обозначение Big O

Java 7 — х  ForkJoinPool , а также Java — 8 в  параллельной Stream  помощи parallelising материал, который является большим при развертывании программы Java на многоядерной процессорной машине. Преимущество такого параллелизма по сравнению с масштабированием на разных машинах в вашей сети заключается в том, что вы можете почти полностью устранить эффекты задержки, поскольку все ядра могут получать доступ к одной и той же памяти.

Но не обманывайтесь эффектом параллелизма! Помните следующие две вещи:

• Параллелизм пожирает ваши ядра. Это отлично подходит для пакетной обработки, но кошмар для асинхронных серверов (таких как HTTP). Есть веские причины, по которым мы использовали однопоточную модель сервлета в последние десятилетия. Так что параллелизм помогает только при расширении.
• Параллелизм не влияет на нотацию Big O вашего алгоритма  . Если ваш алгоритм работает  O(n log n), и вы позволяете этому алгоритму работать на  c ядрах, у вас все еще будет  O(n log n / c) алгоритм, как  c незначительная константа в сложности вашего алгоритма. Вы сэкономите время настенных часов, но не уменьшите сложность!

Конечно, лучший способ повысить производительность — это уменьшить сложность алгоритма. Убийца — это достижение  O(1) или квази- O(1)конечно, например, HashMap поиск. Но это не всегда возможно, не говоря уже о легкости.

Если вы не можете уменьшить свою сложность, вы все равно можете получить большую производительность, если вы настроите свой алгоритм там, где это действительно важно, если сможете найти правильные места. Предположим следующее визуальное представление алгоритма:

Общая сложность алгоритма  O(N3), или,  O(N x O x P) если мы хотим иметь дело с отдельными порядками. Однако при профилировании этого кода вы можете найти забавный сценарий:

• В вашем окне разработки левая ветвь ( N -> M -> Heavy operation) — это единственная ветвь, которую вы можете видеть в своем профилировщике, потому что значения для  O и  P малы в данных примера разработки.
• На производстве, однако, правильная ветвь ( N -> O -> P -> Easy operation или также  NOPE ) действительно вызывает проблемы. Ваша рабочая группа могла бы выяснить это с помощью  AppDynamics ,  DynaTrace или какого-либо подобного программного обеспечения.

Без производственных данных вы можете быстро сделать выводы и оптимизировать «тяжелую работу». Вы отправляете в производство, и ваше исправление не имеет никакого эффекта.

Не существует золотых правил для оптимизации, кроме фактов, которые:

• Хорошо спроектированное приложение гораздо проще оптимизировать
• Преждевременная оптимизация не решит никаких проблем с производительностью, но сделает ваше приложение менее разработанным, что, в свою очередь, затруднит оптимизацию.

Достаточно теории. Давайте предположим, что вы нашли правильную ветвь, чтобы быть проблемой. Вполне может быть , что очень легкая операция взрывает в производстве, так как это называется много и много раз (если  N,  Oи  P большие). Пожалуйста, прочтите эту статью в контексте проблемы на конечном узле неизбежного  O(N3) алгоритма. Эти оптимизации не помогут вам масштабироваться. Они помогут вам сэкономить день вашего клиента, отложив сложное улучшение общего алгоритма на потом!

Вот 10 самых простых оптимизаций производительности в Java:

1. Используйте StringBuilder

Это должно быть по умолчанию почти во всем коде Java. Старайтесь избегать  +оператора. Конечно, вы можете утверждать, что это просто синтаксический сахар для StringBuilder любого, как в:

String x = "a" + args.length + "b";

… который компилируется в

 0  new java.lang.StringBuilder [16]
 3  dup
 4  ldc <String "a"> [18]
 6  invokespecial java.lang.StringBuilder(java.lang.String) [20]
 9  aload_0 [args]
10  arraylength
11  invokevirtual java.lang.StringBuilder.append(int) : java.lang.StringBuilder [23]
14  ldc <String "b"> [27]
16  invokevirtual java.lang.StringBuilder.append(java.lang.String) : java.lang.StringBuilder [29]
19  invokevirtual java.lang.StringBuilder.toString() : java.lang.String [32]
22  astore_1 [x]

Но что произойдет, если позже вам понадобится изменить строку с дополнительными частями?

String x = "a" + args.length + "b";
 
if (args.length == 1)
    x = x + args[0];

Теперь у вас будет секунда  StringBuilder, которая просто излишне потребляет память из вашей кучи, оказывая давление на ваш GC. Напишите это вместо:

StringBuilder x = new StringBuilder("a");
x.append(args.length);
x.append("b");
 
if (args.length == 1);
    x.append(args[0]);

навынос

В приведенном выше примере это, вероятно, совершенно не имеет значения, если вы используете явные  StringBuilder экземпляры, или если вы полагаетесь на компилятор Java, создающий для вас неявные экземпляры. Но помните, мы в  филиале NOPE . Каждый цикл ЦП, который мы тратим на такую ​​глупость, как GC или выделение  StringBuilderемкости по умолчанию, мы тратим N x O x Pвремя впустую  .

Как правило, всегда используйте  StringBuilder вместо  + оператора. И если вы можете, сохраните  StringBuilder ссылку на несколько методов, если ваш  String сложнее построить. Это то, что   делает jOOQ , когда вы генерируете сложный оператор SQL. Есть только один,  StringBuilder который «пересекает» весь ваш SQL  AST (абстрактное синтаксическое дерево)

И для того, чтобы выкрикнуть вслух, если у вас еще есть  StringBuffer ссылки, замените их на  StringBuilder. Вам действительно никогда не нужно синхронизироваться на создаваемой строке.

2. Избегайте регулярных выражений

Регулярные выражения  относительно  дешевы и удобны. Но если вы находитесь в ветке N.OPE , они о худшем, что вы можете сделать. Если вам абсолютно необходимо использовать регулярные выражения в разделах кода, требующих Pattern большого объема вычислений, по крайней мере кэшируйте  ссылку вместо того, чтобы постоянно компилировать ее заново:

static final Pattern HEAVY_REGEX = 
    Pattern.compile("(((X)*Y)*Z)*");

Но если ваше регулярное выражение действительно глупо, как

String[] parts = ipAddress.split("\\.");

… Тогда вам действительно лучше прибегнуть к обычным  char[] или основанным на индексах манипуляциям. Например, этот совершенно нечитаемый цикл делает то же самое:

int length = ipAddress.length();
int offset = 0;
int part = 0;
for (int i = 0; i < length; i++) {
    if (i == length - 1 || 
            ipAddress.charAt(i + 1) == '.') {
        parts[part] = 
            ipAddress.substring(offset, i + 1);
        part++;
        offset = i + 2;
    }
}

… что также показывает, почему не следует делать преждевременную оптимизацию По сравнению с  split() версией это невозможно.

Задача: умные из ваших читателей могут найти  еще более быстрые алгоритмы.

навынос

Регулярные выражения полезны, но они имеют свою цену. Если вы глубоко в  ветке NOPE , вы должны избегать регулярных выражений любой ценой. Остерегайтесь разнообразных методов JDK String, которые используют регулярные выражения, такие как  String.replaceAll(), или  String.split().

 Вместо этого используйте популярную библиотеку, например  Apache Commons Lang , для манипулирования строками.

3. Не используйте итератор ()

Теперь этот совет на самом деле не для общих случаев использования, а применим только в глубине  ветви NOPE . Тем не менее, вы должны подумать об этом. Написание циклов foreach в стиле Java-5 удобно. Вы можете просто полностью забыть о внутреннем цикле и написать:

for (String value : strings) {
    // Do something useful here
}

Однако каждый раз, когда вы запускаете этот цикл, если он  strings есть  Iterable, вы создаете новый  Iterator экземпляр. Если вы используете  ArrayList, это будет выделение объекта с 3  ints в вашей куче:

private class Itr implements Iterator<E> {
    int cursor;
    int lastRet = -1;
    int expectedModCount = modCount;
    // ...

Вместо этого вы можете записать следующий эквивалентный цикл и «тратить» только одно int значение в стеке, что очень дешево:

int size = strings.size();
for (int i = 0; i < size; i++) {
    String value : strings.get(i);
    // Do something useful here
}

навынос

Итераторы, Iterable и цикл foreach чрезвычайно полезны с точки зрения удобочитаемости и читаемости, а также с точки зрения разработки API. Однако они создают небольшой новый экземпляр в куче для каждой отдельной итерации. Если вы выполняете эту итерацию много раз, вы должны избегать создания этого бесполезного экземпляра и вместо этого записывать итерации на основе индекса.

4. Не вызывайте этот метод

Некоторые методы просто дороги. В нашем   примере ветки NOPE такого метода у нас нет, но у вас вполне может быть такой. Давайте предположим, что вашему драйверу JDBC нужно пройти невероятные проблемы, чтобы вычислить значение  ResultSet.wasNull(). Ваш доморощенный код SQL-фреймворка может выглядеть так:

if (type == Integer.class) {
    result = (T) wasNull(rs, 
        Integer.valueOf(rs.getInt(index)));
}
 
// And then...
static final <T> T wasNull(ResultSet rs, T value) 
throws SQLException {
    return rs.wasNull() ? null : value;
}

Эта логика теперь будет вызываться  ResultSet.wasNull() каждый раз, когда  вы получаете результат  intиз набора результатов. Но  getInt() контракт гласит:

Возвращает: значение столбца; если значение равно SQL NULL, возвращаемое значение равно 0

Таким образом, простым, но, возможно, радикальным улучшением вышесказанного будет:

static final <T extends Number> T wasNull(
    ResultSet rs, T value
) 
throws SQLException {
    return (value == null || 
           (value.intValue() == 0 && rs.wasNull())) 
        ? null : value;
}

Итак, это не просто:

навынос

Не называйте дорогие методы в алгоритме «конечными узлами», а вместо этого кэшируйте вызов или избегайте его, если это позволяет контракт метода.

5. Используйте примитивы и стек

Приведенный выше пример из  jOOQ , который использует много дженериков, и , таким образом, вынуждены использовать обертку для типов  byte,  short,  intи  long — по крайней мере , до дженериков будет specialisable в Java 10 и проекта Валгаллу . Но у вас может не быть этого ограничения в вашем коде, поэтому вы должны принять все меры для замены:

// Goes to the heap
Integer i = 817598;

… этим:

// Stays on the stack
int i = 817598;

Ситуация ухудшается, когда вы используете массивы:

// Three heap objects!
Integer[] i = { 1337, 424242 };

… этим

// One heap object.
int[] i = { 1337, 424242 };

навынос

Когда вы глубоко в своей  ветке NOPE , вы должны быть крайне осторожны с использованием типов оболочки. Скорее всего, вы создадите большое давление на свой сборщик мусора, который должен постоянно вставлять, чтобы навести порядок.

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

Trove4j , который поставляется с LGPL, int[] является  отличной библиотекой для примитивных коллекций, которые немного сложнее, чем в среднем  .

Boolean a1 = true; // ... syntax sugar for:
Boolean a2 = Boolean.valueOf(true);
 
Byte b1 = (byte) 123; // ... syntax sugar for:
Byte b2 = Byte.valueOf((byte) 123);

for (K key : map.keySet()) {
    V value : map.get(key);
}

for (Entry<K, V> entry : map.entrySet()) {
    K key = entry.getKey();
    V value = entry.getValue();
}

private transient Object[] vals;
 
public V put(K key, V value) {
    // ...
    int index = key.ordinal();
    vals[index] = maskNull(value);
    // ...
}

// AbstractTable, a common Table base implementation:
 
@Override
public int hashCode() {
 
    // [#1938] This is a much more efficient hashCode()
    // implementation compared to that of standard
    // QueryParts
    return name.hashCode();
}

// AbstractQueryPart, a common AST element
// base implementation:
 
@Override
public int hashCode() {
    // This is a working default implementation. 
    // It should be overridden by concrete subclasses,
    // to improve performance
    return create().renderInlined(this).hashCode();
}

// AbstractTable, a common Table base implementation:
 
@Override
public boolean equals(Object that) {
    if (this == that) {
        return true;
    }
 
    // [#2144] Non-equality can be decided early, 
    // without executing the rather expensive
    // implementation of AbstractQueryPart.equals()
    if (that instanceof AbstractTable) {
        if (StringUtils.equals(name, 
            (((AbstractTable<?>) that).name))) {
            return super.equals(that);
        }
 
        return false;
    }
 
    return false;
}

SomeSet INTERSECT SomeOtherSet

// Pre-Java 8
Set result = new HashSet();
for (Object candidate : someSet)
    if (someOtherSet.contains(candidate))
        result.add(candidate);
 
// Even Java 8 doesn't really help
someSet.stream()
       .filter(someOtherSet::contains)
       .collect(Collectors.toSet());

SomeSet INTERSECT SomeOtherSet