Русский
Русский
English
Статистика
Реклама

Stackwalker

Перевод Как я сократил время загрузки GTA Online на 70

01.03.2021 16:18:41 | Автор: admin
GTA Online. Многопользовательская игра, печально известная медленной загрузкой. Недавно я вернулся, чтобы завершить несколько ограблений и был потрясён, что она загружается настолько же медленно, как и в день своего выпуска, 7 лет назад.

Пришло время докопаться до сути.

Разведка


Сначала я хотел проверить, вдруг кто-то уже решил проблему. Но нашёл только рассказы о великой сложности игры, из-за чего она так долго загружается, истории о том, что сетевая p2p-архитектура мусор (хотя это не так), некоторые сложные способы загрузки в сюжетный режим, а потом в одиночную сессию, и ещё пару модов, чтобы скипнуть видео с логотипом R* во время загрузки. Ещё немного почитав форумы, я узнал, что можно сэкономить колоссальные 10-30 секунд, если использовать все эти способы вместе!

Тем временем на моём компе

Бенчмарк


Story mode load time:  ~1m 10sOnline mode load time: ~6m flatStartup menu disabled, time from R* logo until in-game (social club login time isn't counted).Old but decent CPU:   AMD FX-8350Cheap-o SSD:          KINGSTON SA400S37120GWe have to have RAM:  2x Kingston 8192 MB (DDR3-1337) 99U5471Good-ish GPU:         NVIDIA GeForce GTX 1070

Знаю, что моё железо устарело, но чёрт возьми, что может замедлить загрузку в 6 раз в онлайн-режиме? Я не мог измерить разницу при загрузке из сюжетного режима в онлайн, как это делали другие. Даже если это сработает, разница небольшая.

Я (не) одинок


Если доверять этому опросу, проблема достаточно широко распространена, чтобы слегка раздражать более 80% игроков. Прошло уже семь лет!



Я немного поискал информацию о тех ~20% счастливчиках, которые загружаются быстрее трёх минут, и нашёл несколько бенчмарков с топовыми игровыми ПК и временем загрузки онлайн-режима около двух минут. Я бы кого-нибудь убил хакнул за такой комп! Действительно похоже на железячную проблему, но что-то не складывается

Почему у них сюжетный режим по-прежнему загружается около минуты? (кстати, при загрузке с M.2 NVMe не учитывались видео с логотипами). Кроме того, загрузка из сюжетного режима в онлайн занимает у них всего минуту, в то время как у меня около пяти. Я знаю, что их железо гораздо лучше, но не в пять же раз.

Высокоточные измерения


Вооружившись таким мощным инструментом, как Диспетчер задач, я приступил к поиску узкого места.



Почти минута уходит на загрузку общих ресурсов, которые нужны и для сюжетного режима, и для онлайна (почти наравне с топовыми ПК), затем GTA в течение четырёх минут полностью нагружает одно ядро CPU, больше ничего не делая.

Использование диска? Нет! Использование сети? Есть немного, но через несколько секунд падает в основном до нуля (кроме загрузки вращающихся информационных баннеров). Использование GPU? Ноль. Память? Вообще ничего

Что это, майнинг биткоинов или что-то такое? Чую здесь код. Очень плохой код.

Единственный поток


На моём старом процессоре AMD восемь ядер, и он ещё молодцом, но это старая модель. Его сделали ещё тогда, когда производительность одного потока у AMD была намного ниже, чем у Intel. Наверное, это главная причина таких различий во времени загрузки.

Что странно, так это способ использования CPU. Я ожидал огромное количество операций чтения с диска или массу сетевых запросов, чтобы организовать сеансы в сети p2p. Но такое? Вероятно, здесь какая-то ошибка.

Профилирование


Профилировщик отличный способ найти узкие места в CPU. Есть только одна проблема большинство из них полагаются на инструментирование исходного кода, чтобы получить идеальную картину происходящего в процессе. А у меня нет исходного кода. Мне также не требуются идеальные показания в микросекундах, у меня узкое место на 4 минуты.

Итак, добро пожаловать в образцы стека (stack sampling). Для приложений с закрытым исходным кодом есть только такой вариант. Сбросьте стек запущенного процесса и местоположение указателя текущей инструкции, чтобы построить дерево вызовов в заданные интервалы. Затем наложите их и получите статистику о том, что происходит. Я знаю только один профилировщик, который может проделать это под Windows. И он не обновлялся уже более десяти лет. Это Люк Stackwalker! Кто-нибудь, пожалуйста, подарите Люку немножко любви :)



Обычно Люк группировал бы одинаковые функции, но у меня нет отладочных символов, поэтому пришлось смотреть на соседние адреса, чтобы искать общие места. И что же мы видим? Не одно, а целых два узких места!

Вниз по кроличьей норе


Позаимствовав у моего друга совершенно законную копию стандартного дизассемблера (нет, я действительно не могу его себе позволить когда-нибудь освою гидру), я пошёл разбирать GTA.



Выглядит совсем неправильно. Да, у большинства топовых игр есть встроенная защита от реверс-инжиниринга, чтобы защититься от пиратов, мошенников и моддеров. Не то чтобы это их когда-то останавливало

Похоже, здесь применили какую-то обфускацию/шифрование, заменив большинство инструкций тарабарщиной. Не волнуйтесь, нужно просто сбросить память игры, пока она выполняет ту часть, на которую мы хотим посмотреть. Инструкции должны быть деобфусцированы перед запуском тем или иным способом. У меня рядом лежал Process Dump, так что я взял его, но есть много других инструментов для подобных задач.

Проблема первая: это strlen?!


Дальнейший разбор дампа выявил один из адресов с некоей меткой strlen, которая откуда-то берётся! Спускаясь вниз по стеку вызовов, предыдущий адрес помечен как vscan_fn, и после этого метки заканчиваются, хотя я вполне уверен, что это sscanf.

Куда ж без графика

Он что-то парсит. Но что? Логический разбор займёт целую вечность, поэтому я решил сбросить некоторые образцы из запущенного процесса с помощью x64dbg. Через несколько шагов отладки выясняется, что это JSON! Он парсит JSON. Колоссальные десять мегабайт JSON'а с записями 63 тыс. предметов.

...,{    "key": "WP_WCT_TINT_21_t2_v9_n2",    "price": 45000,    "statName": "CHAR_KIT_FM_PURCHASE20",    "storageType": "BITFIELD",    "bitShift": 7,    "bitSize": 1,    "category": ["CATEGORY_WEAPON_MOD"]},...

Что это? Судя по некоторым ссылкам, это данные для сетевого торгового каталога. Предполагаю, он содержит список всех возможных предметов и обновлений, которые вы можете купить в GTA Online.

Проясним некоторую путаницу: я полагаю, что это предметы, приобретаемые за игровые деньги, не связанные напрямую с микротранзакциями.

10 мегабайт? В принципе, не так уж и много. Хотя sscanf используется не самым оптимальным образом, но, конечно, это не так уж плохо? Что ж



Да, такая процедура займёт некоторое время Честно говоря, я понятия не имел, что большинство реализаций sscanf вызывают strlen, поэтому не могу винить разработчика, который написал это. Я бы предположил, что он просто сканировал байт за байтом и мог остановиться на NULL.

Проблема вторая: давайте использовать хэш-массив?


Оказывается, второго преступника вызывают сразу за первым. Даже в одной и той же конструкции if, как видно из этой уродливой декомпиляции:



Все метки мои, и я понятия не имею, как на самом деле называются функции/параметры.

Вторая проблема? Сразу после разбора элемента он хранится в массиве (или встроенном списке C++? не уверен). Каждая запись выглядит примерно так:

struct {    uint64_t *hash;    item_t   *item;} entry;

А перед сохранением? Он проверяет весь массив, сравнивая хэш каждого элемента, есть он в списке или нет. С 63 тыс. записей это примерно (n^2+n)/2 = (63000^2+63000)/2 = 1984531500, если я не ошибаюсь в расчётах. И это в основном бесполезные проверки. У вас есть уникальные хэши, почему не использовать хэш-карту.



Во время реверс-инжиниринга я назвал его hashmap, но это явно не_hashmap. И дальше ещё интереснее. Этот хэш-массив-список пуст перед загрузкой JSON. И все элементы в JSON уникальны! Им даже не нужно проверять, есть они в списке или нет! У них даже есть функция прямой вставки элементов! Просто используйте её! Серьёзно, ну ребята, что за фигня!?

PoC


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

План такой. 1. Написать .dll, 2. внедрить её в GTA, 3. зацепить некоторые функции, 4. ???, 5. профит. Всё предельно просто.

Проблема с JSON нетривиальная, я не могу реально заменить их парсер. Более реалистичным кажется заменить sscanf на тот, который не зависит от strlen. Но есть ещё более простой способ.

  • зацепить strlen
  • подождать длинной строки
  • закэшировать начало и длину
  • если поступит ещё вызов в пределах диапазона строки, вернуть закэшированное значение

Что-то вроде такого:

size_t strlen_cacher(char* str){  static char* start;  static char* end;  size_t len;  const size_t cap = 20000;  // if we have a "cached" string and current pointer is within it  if (start && str >= start && str <= end) {    // calculate the new strlen    len = end - str;    // if we're near the end, unload self    // we don't want to mess something else up    if (len < cap / 2)      MH_DisableHook((LPVOID)strlen_addr);    // super-fast return!    return len;  }  // count the actual length  // we need at least one measurement of the large JSON  // or normal strlen for other strings  len = builtin_strlen(str);  // if it was the really long string  // save it's start and end addresses  if (len > cap) {    start = str;    end = str + len;  }  // slow, boring return  return len;}


А что касается проблемы хэш-массива, то здесь просто полностью пропускаем все проверки и вставляем элементы напрямую, поскольку мы знаем, что значения уникальны.

char __fastcall netcat_insert_dedupe_hooked(uint64_t catalog, uint64_t* key, uint64_t* item){  // didn't bother reversing the structure  uint64_t not_a_hashmap = catalog + 88;  // no idea what this does, but repeat what the original did  if (!(*(uint8_t(__fastcall**)(uint64_t*))(*item + 48))(item))    return 0;  // insert directly  netcat_insert_direct(not_a_hashmap, key, &item);  // remove hooks when the last item's hash is hit  // and unload the .dll, we are done here :)  if (*key == 0x7FFFD6BE) {    MH_DisableHook((LPVOID)netcat_insert_dedupe_addr);    unload();  }  return 1;}

Полный исходный код PoC здесь.

Результаты


Ну и как оно работает?

Original online mode load time:        ~6m flatTime with only duplication check patch: 4m 30sTime with only JSON parser patch:       2m 50sTime with both issues patched:          1m 50s(6*60 - (1*60+50)) / (6*60) = 69.4% load time improvement (nice!)

Да, чёрт возьми, получилось! :))

Скорее всего, это не решит всех проблем с загрузкой в разных системах могут быть и другие узкие места, но это такая зияющая дыра, что я понятия не имею, как R* пропустила её за все эти годы.

Краткое содержание


  • При запуске GTA Online есть узкое место, связанное с однопоточным вычислением
  • Оказалось, GTA изо всех сил пытается распарсить 1-мегабайтный файл JSON
  • Сам парсер JSON плохо сделан/наивен и
  • После парсинга происходит медленная процедура удаления дублей

R*, пожалуйста, исправьте


Если информация каким-то образом дойдёт до инженеров Rockstar, то проблему можно решить в течение нескольких часов силами одного разработчика. Пожалуйста, ребята, сделайте что-нибудь с этим :<

Вы можете либо перейти на хэш-карту для удаления дублей, либо полностью пропустить дедупликацию при запуске как быстрое исправление. Для парсера JSON просто замените библиотеку на более производительную. Не думаю, что есть более простой вариант.

ty <3
Подробнее..

API, ради которых наконец-то стоит обновиться с Java 8. Часть 3

24.04.2021 18:16:03 | Автор: admin

Какие есть причины переходить на новые версии Java? Кто-то это сделает из-за новых языковых возможностей вроде выражений switch, блоков текста или записей. Кому-то понадобятся новые интересные возможности вроде модулей или низкопаузных сборщиков мусора. Кто-то это сделает просто из-за того, что обновив версию Java, их программа станет быстрее и будет есть меньше памяти. Но есть ещё одна, не менее важная причина. Это новые API, которые позволят писать меньше кода и избежать траты времени на поиск нужной функциональности во внешних библиотеках. А в некоторых случаях сделают ваш код быстрее.


В предыдущих двух частях мы уже рассмотрели по 10 новых API, которые появились в Java 9 и более поздних версиях (часть 1, часть 2). Сегодня мы рассмотрим ещё 10.




1. Stream.toList()


Появился в: Java 16


Для какой задачи чаще всего используется Stream в Java? Конечно же, для трансформации списков: у нас есть список, над которым нужно совершить какое-то преобразование и вернуть новый. Такой паттерн вы наверняка видели в своём проекте множество раз:


List<T> targetList = sourceList        .stream()        // промежуточные операции        .collect(Collectors.toList());

Нельзя сказать, что collect(Collectors.toList()) является очень уж громоздкой конструкцией, но всё же хочется для такой частой операции писать поменьше кода. И в Java 16 это стало возможно с помощью нового метода Stream.toList():


List<T> targetList = sourceList        .stream()        // промежуточные операции        .toList();

Есть ли какая-то разница между toList() и collect(Collectors.toList())? Оба ли способа ведут себя одинаково? С практической точки зрения можно сказать, что нет: если toList() возвращает неизменяемый список, то collect(Collectors.toList()) возвращает некий список, о котором неизвестно, неизменяемый он или нет. То есть если вы нигде в коде не используете негарантированную вам спецификацией изменяемость списка (надеюсь, вы из такой категории людей), то смело можете заменять collect(Collectors.toList()) на toList().


Однако Stream.toList() делает код не только короче, но и эффективнее! Дело в том, что Stream.toList() использует внутри себя Stream.toArray(), который выделяет массив точной длины, если Spliterator имеет характеристику SIZED. В то время как Collectors.toList() никак эту характеристику не использует и всегда начинает с пустого ArrayList, накапливая в нём элементы с постоянными переаллокациями.


Давайте напишем несколько бенчмарков. Для начала рассмотрим самый простейший случай: замерим, как быстро создаётся копия исходного списка, т.е. проверим цепочку вообще без промежуточных операций. Так как для такого сценария Stream по идее вообще не нужен, и того же самого можно добиться просто вызвав new ArrayList<>(sourceList) или List.copyOf(sourceList), то замерим и эти два случая тоже:


Полный код JMH-бенчмарка
import org.openjdk.jmh.annotations.*;import java.util.ArrayList;import java.util.List;import java.util.concurrent.TimeUnit;import java.util.stream.Collectors;import java.util.stream.IntStream;@BenchmarkMode(Mode.AverageTime)@OutputTimeUnit(TimeUnit.NANOSECONDS)@State(Scope.Thread)public class ToList {    @Param({"10", "100", "1000"})    private int size;    private List<Integer> sourceList;    @Setup    public void setup() {        sourceList = IntStream                .range(0, size)                .boxed()                .collect(Collectors.toList());    }    @Benchmark    public List<Integer> newArrayList() {        return new ArrayList<>(sourceList);    }    @Benchmark    public List<Integer> toList() {        return sourceList.stream().toList();    }    @Benchmark    public List<Integer> copyOf() {        return List.copyOf(sourceList);    }    @Benchmark    public List<Integer> collectToList() {        return sourceList.stream().collect(Collectors.toList());    }    @Benchmark    public List<Integer> collectToUnmodifiableList() {        return sourceList.stream().collect(Collectors.toUnmodifiableList());    }}

Детали запуска бенчмарка
OpenJDK 64-Bit Server VM (build 16+36-2231, mixed mode, sharing)Intel Core i5-9500 3.00GHZОпции запуска: -f 3 -wi 3 -w 5 -i 5 -r 5 -t 6 -jvmArgs -XX:+UseParallelGC


Результаты говорят нам о том, что Stream.toList() не только существенно быстрее collect(Collectors.toList()), но и может быть быстрее даже List.copyOf()! Это объясняется тем, что в List.copyOf() существенное время тратится на проверку requireNonNull для каждого входного элемента, поскольку он запрещает null-элементы, в то время как Stream.toList() не запрещает null и в нём такая проверка не нужна. На малых размерах List.copyOf() всё же выигрывает, потому что проверка нескольких элементов на null быстрее церемоний, которые есть у Stream: создание Spliterator, ReferencePipeline и т.д.


Теперь рассмотрим случай, когда точный размер неизвестен. Например, добавим одну промежуточную операцию filter():


Полный код JMH-бенчмарка
import org.openjdk.jmh.annotations.*;import java.util.ArrayList;import java.util.List;import java.util.concurrent.TimeUnit;import java.util.stream.Collectors;import java.util.stream.IntStream;@BenchmarkMode(Mode.AverageTime)@OutputTimeUnit(TimeUnit.NANOSECONDS)@State(Scope.Thread)public class ToListFilter {    @Param({"10", "100", "1000"})    private int size;    private List<Integer> sourceList;    @Setup    public void setup() {        sourceList = IntStream                .range(0, size)                .boxed()                .collect(Collectors.toList());    }    @Benchmark    public List<Integer> toList() {        return sourceList.stream().filter(i -> i % 2 == 0).toList();    }    @Benchmark    public List<Integer> newArrayList() {        var list = new ArrayList<Integer>();        for (var i : sourceList) {            if (i % 2 == 0) {                list.add(i);            }        }        return list;    }    @Benchmark    public List<Integer> collectToList() {        return sourceList.stream().filter(i -> i % 2 == 0).collect(Collectors.toList());    }    @Benchmark    public List<Integer> collectToUnmodifiableList() {        return sourceList.stream().filter(i -> i % 2 == 0).collect(Collectors.toUnmodifiableList());    }}

Детали запуска бенчмарка
OpenJDK 64-Bit Server VM (build 16+36-2231, mixed mode, sharing)Intel Core i5-9500 3.00GHZОпции запуска: -f 3 -wi 3 -w 5 -i 5 -r 5 -t 6 -jvmArgs -XX:+UseParallelGC



В этом случае мы тоже получили большое ускорение! И в этот раз Stream.toList() на большом количестве элементов выиграл даже у простого new ArrayList() с последующим заполнением в цикле. Как так получается? Дело в том, что при неизвестном размере Stream.toArray() использует структуру данных SpinedBuffer, которая более эффективна для накопления элементов, чем ArrayList. Она представляет собой массив массивов, где подмассивы имеют длины в виде возрастающих степеней двойки (каждый следующий chunk в два раза больше предыдущего). Структуру SpinedBuffer можно легко понять из этого рисунка, где изображён буфер со 100 элементами (Integer от 0 до 99):



Также ArrayList проигрывает ещё и потому, что расширяется всего лишь в 1.5 раза при заполнении внутреннего массива, а значит делает это намного чаще, что приводит к дополнительным накладным расходам. ArrayList вынужден балансировать между экономией памяти и скоростью операции add(), поэтому и проигрывает SpinedBuffer, который заточен исключительно на скорость. Излишний расход памяти для него не играет роли, так как это недолгоживующая структура, которая сразу же отбрасывается после завершения терминальной операции.


Вывод: Stream.toList() короче, чище и почти всегда быстрее, чем collect(Collectors.toList()). Так что о втором способе можно забыть и использовать всегда первый (хотя Collectors.toList() сам по себе всё ещё может быть нужен, например как downstream Collector для других Collector'ов). Если же нужен гарантированно изменяемый список, то можно использовать collect(Collectors.toCollection(ArrayList::new)).



2. String: formatted(), stripIndent() и translateEscapes()


Появились в: Java 15


В Java 15 появились блоки текста строковые литералы, которые могут состоять из одной или нескольких линий:


String str = """        Привет,        Юзер!""";

При этом довольно часто блоки будут использоваться в качестве шаблонов с последующей заменой:


String str = String.format("""        Привет,        %s!""", user);

Не кажется ли вам, что код выше выглядит несколько громоздким? Мне вот тоже кажется. Но у нас есть способ, как сделать его немножко чище. Это новый метод String.formatted(), который является нестатическим эквивалентом String.format():


String str = """        Привет,        %s!""".formatted(user);

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


Кстати, formatted() никто не запрещает использовать и с обычными литералами:


String str = "Привет, %s!".formatted(user);

Лично мне метод очень нравится, и я планирую взять его на вооружение в качестве основного рабочего варианта.



Второй метод, появившийся в Java 15 это String.stripIndent(), который удаляет общие пробельные символы в начале всех линий. К примеру, если есть файл hello.txt с такими строками:


    Привет,    Юзер!

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


String str = Files.readString(Path.of("hello.txt")).stripIndent();System.out.println(str);

Вывод:


Привет,Юзер!


Наконец, третий метод это String.translateEscapes(). Он делает простую вещь: заменяет экранирующие последовательности на их соответствующие символы.


Например, есть файл hello.txt:


Привет,\nЮзер!

String str = Files.readString(Path.of("hello.txt")).translateEscapes();System.out.println(str);

Вывод:


Привет,Юзер!


3. CharSequence.isEmpty(), CharSequence.compare() и StringBuilder.compareTo()


Появились в: Java 15 / Java 11


Если уж мы начали тему строк, то давайте добьём её до конца.


Тот, кто писал на Java 1.5 или на более старых версиях, должен помнить, что в классе String в те времена не было метода isEmpty(). Поэтому для проверки строки на пустоту каждый раз приходилось использовать length():


if (str.length() != 0) {    ...}

Это было не совсем удобно, и в Java 1.6 метод String.isEmpty() наконец-то завезли:


if (!str.isEmpty()) {    ...}

Однако про то, что String далеко не единственная реализация CharSequence (хоть и самая популярная), почему-то не подумали, и этот метод туда добавлять не стали (впрочем, без default-методов они бы этого сделать и не смогли). Например, для проверки на пустоту StringBuilder всё ещё приходилось использовать length():


if (stringBuilder.length() != 0) {    ...}

Но спустя 14 лет всё-таки решили исправить и это: начиная с Java 15, метод isEmpty() есть не только у String, но и у любой CharSequence:


if (!stringBuilder.isEmpty()) {    ...}


Также иногда приходится тестировать два CharSequence на равенство. Метод equals() использовать нельзя: а вдруг он не переопределён в реализации? Поэтому приходится изворачиваться: либо конвертировать каждый CharSequence в String и сравнивать их, что может быть накладно, либо писать свою реализацию посимвольного сравнения.


Однако, начиная с Java 11, всё это не нужно, потому что появился метод CharSequence.compare():


if (CharSequence.compare(charSeq1, charSeq2) == 0) {    ...}

Метод compare() также можно использовать не только для просто теста на равенство, но и для лексикографического сравнения.


Также в Java 11 класс StringBuilder стал реализовывать интерфейс Comparable, а значит для сравнения двух StringBuilder можно использовать compareTo():


if (stringBuilder1.compareTo(stringBuilder2) == 0) {    ...}


4. Collectors.filtering() и Collectors.flatMapping()


Появились в: Java 9


Часто ли вам приходится использовать Collectors.groupingBy()? К примеру, вы ведёте базу данных фильмов:


record Movie(String title, String genre, double rating) {}

Допустим, вы хотите сгруппировать фильмы по жанру:


Stream<Movie> allMovies = Stream.of(    new Movie("Коммандо", "Боевик", 7.385),    new Movie("Терминатор", "Боевик", 7.974),    new Movie("Терминатор 2", "Боевик", 8.312),    new Movie("Молчание ягнят", "Триллер", 8.33),    new Movie("Криминальное чтиво", "Триллер", 8.619),    new Movie("Титаник", "Мелодрама", 8.363),    new Movie("Семьянин", "Комедия", 7.699));Map<String, List<Movie>> groups = allMovies.collect(    Collectors.groupingBy(Movie::genre));groups.forEach((genre, movies) -> {    System.out.println(genre + ":");    movies.forEach(movie ->        System.out.printf("    %s: %.2f%n", movie.title(), movie.rating()));});

Вывод:


Мелодрама:    Титаник: 8.36Боевик:    Коммандо: 7.39    Терминатор: 7.97    Терминатор 2: 8.31Триллер:    Молчание ягнят: 8.33    Криминальное чтиво: 8.62Комедия:    Семьянин: 7.70

Однако, допустим, вы не хотите видеть все фильмы, а только те, у кого рейтинг выше 8. Какой метод вы в этом случае используете? Конечно же, Stream.filter():


Map<String, List<Movie>> groups = allMovies    .filter(movie -> movie.rating() > 8)    .collect(Collectors.groupingBy(Movie::genre));

Мелодрама:    Титаник: 8.36Боевик:    Терминатор 2: 8.31Триллер:    Молчание ягнят: 8.33    Криминальное чтиво: 8.62

Но вот проблема: вам вдруг захотелось видеть все жанры, даже те, в которые не попало ни одного фильма с рейтингом выше 8. Что делать? Ответ: перейти на новую версию Java, потому что в ней есть Collectors.filtering():


Map<String, List<Movie>> groups = allMovies.collect(    Collectors.groupingBy(Movie::genre,        Collectors.filtering(movie -> movie.rating() > 8,            Collectors.toList())));groups.forEach((genre, movies) -> {    System.out.println(genre + ":");    if (movies.isEmpty()) {        System.out.println("    <Фильмов с рейтингом выше 8 нет>");    } else {        movies.forEach(movie ->            System.out.printf("    %s: %.2f%n", movie.title(), movie.rating()));    }});

В этом случае фильтрация будет перенесена внутрь groupingBy(), и потери жанров не произойдёт:


Мелодрама:    Титаник: 8.36Боевик:    Терминатор 2: 8.31Триллер:    Молчание ягнят: 8.33    Криминальное чтиво: 8.62Комедия:    <Фильмов с рейтингом выше 8 нет>


Очень хорошо. Теперь добавим в фильмы актёров:


record Movie(String title, String genre, double rating, List<String> actors) {}

И теперь хотите увидеть всех актёров с группировкой по жанру:


Stream<Movie> allMovies = Stream.of(    new Movie("Коммандо", "Боевик", 7.385,        List.of("Шварценеггер", "Чонг", "Хедайя")),    new Movie("Терминатор", "Боевик", 7.974,        List.of("Шварценеггер", "Бин", "Хэмилтон")),    new Movie("Терминатор 2", "Боевик", 8.312,        List.of("Шварценеггер", "Хэмилтон", "Ферлонг", "Патрик")),    new Movie("Молчание ягнят", "Триллер", 8.33,        List.of("Фостер", "Хопкинс")),    new Movie("Криминальное чтиво", "Триллер", 8.619,        List.of("Траволта", "Уиллис", "Джексон", "Турман")),    new Movie("Титаник", "Мелодрама", 8.363,        List.of("ДиКаприо", "Уинслет")),    new Movie("Семьянин", "Комедия", 7.699,        List.of("Кейдж", "Леони")));

Но какой коллектор нужно подсунуть в groupingBy(), чтобы собрать всех актёров в Set? Можно попробовать Collectors.mapping():


Map<String, Set<List<String>>> groups = allMovies.collect(    Collectors.groupingBy(Movie::genre,        Collectors.mapping(Movie::actors, Collectors.toSet())));

Но смотрите, у нас получилось множество списков, а нужно просто множество. Что же делать? И тут на помощь приходит Collectors.flatMapping(), ещё один новый метод, появившийся в Java 9:


Map<String, Set<String>> groups = allMovies.collect(    Collectors.groupingBy(Movie::genre,        Collectors.flatMapping(movie -> movie.actors().stream(),            Collectors.toSet())));

И вот сейчас тип правильный! Если вывести это, то получится:


Мелодрама:    ДиКаприо    УинслетБоевик:    Бин    Ферлонг    Хедайя    Патрик    Шварценеггер    Хэмилтон    ЧонгТриллер:    Траволта    Уиллис    Хопкинс    Фостер    Джексон    ТурманКомедия:    Кейдж    Леони

Что и требовалось.



5. StackWalker


Появился в: Java 9


Приходилось ли вам иметь дело со стеками? Не со стеками в смысле структур данных, а со стеком потоков? Например, вы пишете простенький логгер:


public final class MyLogger {    public static void log(String message) {        System.out.println(message);    }}

Однако вы хотите писать в консоль не просто голое сообщение, а ещё имя класса, метода, файла и номер строки, откуда вызывается метод log(). В Java 8 единственным стандартным способом для этого является получение массива StackTraceElement[], например, с помощью метода Thread.getStackTrace():


public static void log(String message) {    StackTraceElement[] stackTrace = Thread.currentThread().getStackTrace();    StackTraceElement stackTraceElement = stackTrace[2];    String msg = stackTraceElement.getClassName() + "."               + stackTraceElement.getMethodName() + "("               + stackTraceElement.getFileName() + ":"               + stackTraceElement.getLineNumber() + ") "               + message;    System.out.println(msg);}

Можно предположить, что такой способ получения получения номеров строк является довольно дорогим. Ведь нам надо заполнить полностью весь стек, который может быть очень глубоким (особенно в энтерпрайзе, где фреймворк на фреймворке), а потом ещё и сконвертировать внутренние структуры JVM в Java-массив. И всё это ради того, чтобы отбросить его почти полностью и достать только второй элемент. Давайте замерим производительность такого подхода:


@Benchmarkpublic String stackTrace() {    StackTraceElement[] stackTrace = Thread.currentThread().getStackTrace();    StackTraceElement stackTraceElement = stackTrace[2];    return stackTraceElement.getClassName() + "."         + stackTraceElement.getMethodName() + "("         + stackTraceElement.getFileName() + ":"         + stackTraceElement.getLineNumber() + ")";}

Детали запуска бенчмарка
OpenJDK 64-Bit Server VM (build 16+36-2231, mixed mode, sharing)Intel Core i5-9500 3.00GHZОпции запуска: -f 1 -wi 3 -w 3 -i 5 -r 5 -t 6

Benchmark          Mode  Cnt    Score   Error  UnitsStack.stackTrace   avgt    5  103,704 ? 1,123  us/op

104 микросекунды на каждый вызов! Это невероятно медленно! Есть ли возможность это ускорить? Есть: с помощью нового класса StackWalker, который появился в Java 9. Давайте рассмотрим этот класс поподробнее.


StackWalker предоставляет возможность гулять по стеку. Чтобы это сделать, сначала нужно получить экземпляр StackWalker с помощью метода StackWalker.getInstance(). Этот метод возвращает StackWalker по умолчанию. Также есть возможность передать в метод getInstance() опции и получить StackWalker с более богатыми возможностями. Но об этом чуть позже.


После того, как мы получил объект StackWalker, у нас есть следующие варианты:


  • Выполнить на нём метод forEach() и пройтись по всем фреймам стека.
  • Вызвать метод getCallerClass() и получить класс, который вызвал наш метод (работает только с опцией RETAIN_CLASS_REFERENCE).
  • Вызвать метод walk(), который принимает функцию из Stream<StackFrame> в T, где T это что угодно. Это самый гибкий метод.

Для нашего логгера мы воспользуемся третьим вариантом. Вот как будет выглядеть реализация метода log():


public static void log(String message) {    String msg = StackWalker        .getInstance()        .walk((Stream<StackFrame> frames) -> {            StackFrame frame = frames.skip(2).findFirst().get();            return frame.getClassName() + "."                 + frame.getMethodName() + "("                 + frame.getFileName() + ":"                 + frame.getLineNumber() + ") "                 + message;        });    System.out.println(msg);}

Теперь давайте замерим производительность варианта со StackWalker:


@Benchmarkpublic String stackWalker() {    return StackWalker        .getInstance()        .walk(frames -> {            StackFrame frame = frames.skip(2).findFirst().get();            return frame.getClassName() + "."                 + frame.getMethodName() + "("                 + frame.getFileName() + ":"                 + frame.getLineNumber() + ")";        });}

Детали запуска бенчмарка
OpenJDK 64-Bit Server VM (build 16+36-2231, mixed mode, sharing)Intel Core i5-9500 3.00GHZОпции запуска: -f 1 -wi 3 -w 3 -i 5 -r 5 -t 6

Benchmark          Mode  Cnt    Score   Error  UnitsStack.stackTrace   avgt    5  103,704 ? 1,123  us/opStack.stackWalker  avgt    5    2,781 ? 0,156  us/op

Скорость выросла в 37 раз! Это огромный выигрыш. Конечно, 2.8 микросекунды это всё ещё далеко не бесплатно, но такой вариант кажется уже вполне приемлемым, чтобы включить его в боевом приложении.


Так как метод StackWalker.walk() даёт нам Stream, то наши возможности по обходу стека практически безграничны: можно получить все фреймы, можно отфильтровать, можно пропустить сколько-то. Например, усложним наш логирующий фреймворк, добавив туда уровни:


package org.mylogger;public final class MyLogger {    public enum Level {        ERROR, WARN, INFO    }    public static void error(String message) {        log(Level.ERROR, message);    }    public static void warn(String message) {        log(Level.WARN, message);    }    public static void info(String message) {        log(Level.INFO, message);    }    public static void log(Level level, String message) {        ...    }}

Сейчас мы уже не можем использовать конструкцию frames.skip(2), потому что метод log() может быть вызван как напрямую, так и через методы error(), warn(), log(), а значит фрейм надо искать немножко умнее. Самое простое через Stream.dropWhile():


public static void log(Level level, String message) {    String msg = StackWalker        .getInstance()        .walk((Stream<StackFrame> frames) -> {            StackFrame frame = frames                .dropWhile(f -> f.getClassName().startsWith("org.mylogger"))                .findFirst()                .get();            return level + " "                 + frame.getClassName() + "."                 + frame.getMethodName() + "("                 + frame.getFileName() + ":"                 + frame.getLineNumber() + ") "                 + message;        });    System.out.println(msg);}


Какие ещё применения есть у StackWalker?


Как вы знаете, в Java 9 появились модули. Но мало кто использует их в своих проектах, и подавляющее большинство всё ещё препочитает класть всё в classpath. Но тогда у нас теряется весьма ценная возможность экспортировать из модуля часть пакетов, а остальные скрывать. Представим, что у нас есть пакет org.example.mylib.internal, который мы хотим, чтобы не использовал никто кроме нашего модуля:


package org.example.mylib.internal;public final class Handler {    public static void handle() {        ...    }}

Класс Handler публичный, а значит компилятор уже никак не помешает кому угодно использовать этот класс. Но, может быть, можно сделать хотя бы проверку в рантайме? И действительно, это можно сделать через StackWalker.getCallerClass(), и выглядеть этот будет примерно так:


package org.example.mylib.internal;public final class Handler {    public static void handle() {        if (!StackWalker            .getInstance(Option.RETAIN_CLASS_REFERENCE)            .getCallerClass()            .getPackageName()            .startsWith("org.example.mylib.")) {            throw new RuntimeException("Security error");        }        ...    }}

Здесь мы использовали опцию RETAIN_CLASS_REFERENCE, иначе получить Class не получилось бы. В принципе, подобную функциональность можно было бы реализовать и через Stream.walk(), но getCallerClass() работает немного быстрее.



6. System.Logger


Появился в: Java 9


Если уж мы начали говорить про логирование, то нельзя не рассказать про новое стандартное API для логирования, которое появилось в Java 9. Это API очень маленькое и состоит всего из трёх классов: интерфейса System.Logger, абстрактного класса System.LoggerFinder и перечисления System.Logger.Level.


Использовать System.Logger чрезвычайно просто:


public final class Main {    private static final Logger LOGGER = System.getLogger("");    public static void main(String[] args)  {        LOGGER.log(Level.ERROR, "Critical error!");    }}

Вывод:


апр. 17, 2021 6:24:57 PM org.example.Main mainSEVERE: Critical error!

System.Logger это не новый очередной фреймворк для логирования, как вы могли бы подумать сначала, а только фронтенд для логирования. Если вы знакомы с существующими фреймворками, то вам должно быть это знакомо: например, SLF4J это фронтенд, а его соответствующим бэкендом является Logback. Или Log4j API это фронтенд для Log4j Core. Так вот, System.Logger это фронтенд для знакомого вам фреймворка java.util.logging, который находится в отдельном модуле java.logging.


При этом нам ничего не мешает для SLF4J использовать другой бэкенд, например, Log4j или java.util.logging. Или для Log4j API использовать SLF4J как бэкенд или java.util.logging. Точно так же и с System.Logger: он спроектирован так, чтобы реализация могла быть абсолютно любой. Если не нравится неудобный и старый java.util.logging, то можно использовать что-то другое. Например, можно его настроить на современный Log4j, для чего потребуется подключить следующие зависимости:


<dependency>    <groupId>org.apache.logging.log4j</groupId>    <artifactId>log4j-api</artifactId>    <version>2.14.1</version> <!-- Последняя версия на момент написания статьи -->    <scope>runtime</scope></dependency><dependency>    <groupId>org.apache.logging.log4j</groupId>    <artifactId>log4j-core</artifactId>    <version>2.14.1</version>    <scope>runtime</scope></dependency><dependency>    <groupId>org.apache.logging.log4j</groupId>    <artifactId>log4j-jpl</artifactId>    <version>2.14.1</version>    <scope>runtime</scope></dependency>

При этом саму программу изменять не потребуется: то, что log4j-jpl окажется в classpath, уже будет достаточно. Java через ServiceLoader найдёт нужную реализацию LoggerFinder в виде Log4jSystemLoggerFinder и будет направлять логи в Log4j:


18:24:57.941 [main] ERROR  - Critical error!

После этого модуль java.logging можно будет даже вообще исключить из JRE/JDK, ведь он больше не нужен (если вы конечно нигде не вызываете java.util.logging напрямую).


К сожалению, адаптера System.Logger для SLF4J/Logback нет. Но тут проблема более глобальная похоже, что сам проект SLF4J мёртв. Последний коммит в GitHub был полтора года назад. Так что Log4j сейчас это самый нормальный вариант он активно развивается и поддерживается.


Несколько примеров использования System.Logger:


LOGGER.log(Level.INFO, "Information");LOGGER.log(Level.DEBUG, "Sum of {} and {} is {}:", 2, 3, 2+3);LOGGER.log(Level.TRACE, () -> "Lazy message");LOGGER.log(Level.ERROR, "Log exception", new Exception());


7. Lookup.defineHiddenClass()


Появился в: Java 15


В прошлый раз мы рассказывали про метод MethodHandles.Lookup.defineClass(), с помощью которого можно во время выполнения легко загрузить класс в том же пакете, не создавая при этом новый загрузчик класса. Это очень удобный метод, но у него есть существенный минус: класс, который загружен таким образом, будет до конца жизни висеть в памяти (по крайней мере до конца жизни текущего загрузчика класса). Это не очень подходит для приложений, которым требуется динамически генерировать и загружать много временных классов на лету. Но с Java 15 появилась альтернатива в виде нового вида классов, которые называются скрытыми.


Скрытые классы создаются с помощью нового метода Lookup.defineHiddenClass(). По сути этот метод очень похож на старый нестандартный метод Unsafe.defineAnonymousClass(), который много лет используется различными фреймворками, поскольку решает проблему неконтролируемого роста количества временных классов в памяти. При этом сам Unsafe.defineAnonymousClass() с Java 15 стал deprecated for removal.


Скрытые классы имеют следующие особенности:


  • На них не могут прямо ссылаться другие классы. Всё их использование может осуществляться исключительно через рефлексию.
  • Они являются необнаружимыми. Их нельзя найти ни по имени, ни обнаружить с помощью загрузчиков классов (через Class.forName(), ClassLoader.loadClass(), ClassLoader.findLoadedClass() и т.д.). Однако скрытые классы не являются анонимными и всё-таки имеют имя в формате <имя класса в байт-коде>/<suffix> (например, org.example.Temp/0x0000000800cb8000).
  • Они реализованы таким способом, что не связаны сильной ссылкой с загрузчиком класса, а значит могут быть собраны сборщиком мусора, когда их Class становится недостижимым (но если хочется, то это можно переопределить, передав опцию ClassOption.STRONG в defineHiddenClass()).
  • Они не появляются в стектрейсах, если только не включить опции -XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames.

Кстати, вы уже должны быть хорошо знакомы со скрытыми классами, поскольку используете их каждый день. Это лямбды:


jshell> Runnable runnable = () -> {}runnable ==> $Lambda$26/0x0000000800c0aa00@443b7951jshell> runnable.getClass().isHidden()$2 ==> true


Давайте создадим небольшой примерчик и определим свой скрытый класс с нуля. Пусть он для простоты складывает два int'а. Для разнообразия будем это делать не с помощью javac, а через ByteBuddy.


Для начала нужно создать представление класса в байт-коде в виде массива байтов:


byte[] bytes = new ByteBuddy()        .subclass(Object.class)        .name("org.example.Temp")        .defineMethod("sum", int.class, Modifier.PUBLIC)        .withParameters(int.class, int.class)        .intercept(new Implementation.Simple(                MethodVariableAccess.INTEGER.loadFrom(1),                MethodVariableAccess.INTEGER.loadFrom(2),                Addition.INTEGER,                MethodReturn.INTEGER))        .make()        .getBytes();

По сути мы скомпилировали вот такой класс, но сделали это в рантайме непосредственно через манипуляции с байт-кодом:


package org.example;public class Temp {    public int sum(int x, int y) {        return x + y;    }}

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


Lookup lookup = MethodHandles        .lookup()        .defineHiddenClass(bytes, false);// Для разнообразия будем использовать MethodHandle вместо reflectionObject obj = lookup        .findConstructor(lookup.lookupClass(), MethodType.methodType(void.class))        .invoke();MethodHandle sumHandle = lookup.findVirtual(lookup.lookupClass(), "sum",        MethodType.methodType(int.class, int.class, int.class));// Вызовем метод sum. Должен напечатать 5System.out.println(sumHandle.invoke(obj, 3, 2));

Вот и всё.



Кстати, так как скрытые классы необнаружимы, то загружать один и тот же класс можно сколько угодно раз. По сути каждый раз будет определяться новый уникальный скрытый класс:


Lookup lookup1 = MethodHandles.lookup().defineHiddenClass(bytes, false);Lookup lookup2 = MethodHandles.lookup().defineHiddenClass(bytes, false);Lookup lookup3 = MethodHandles.lookup().defineHiddenClass(bytes, false);System.out.println(lookup1.lookupClass()); // class org.example.Temp/0x0000000800cb4000System.out.println(lookup2.lookupClass()); // class org.example.Temp/0x0000000800cb4400System.out.println(lookup3.lookupClass()); // class org.example.Temp/0x0000000800cb4800


8. Новые методы в Math


Появились в: Java 9 / Java 15


Наверное, практически все, кто начинал работать с большими числами в Java, совершал вот такую ошибку:


int x = ...int y = ...long z = x * y;

Это один из тех примеров в Java, когда можно угодить в ловушку даже на простом умножении: произведение двух int это тоже int, а значит то, что переменная z имеет тип long, от переполнения никак не спасает. Для исправления этой ошибки нужно явно прикастовать хотя бы один из множителей к long:


long z = (long) x * y;

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


Возьми два int и перемножь их в long с учётом переполнения

И с Java 9 такой способ есть. Это метод Math.multiplyFull():


long z = Math.multiplyFull(x, y);


Вообще обработка переполнений в Java реализуется довольно муторно, и чтобы облегчить жизнь программистам, в Java 8 появилась целая пачка методов для этого в классе Math:


  • int toIntExact(long value)
  • int incrementExact(int a)
  • long incrementExact(long a)
  • int decrementExact(int a)
  • long decrementExact(long a)
  • int negateExact(int a)
  • long negateExact(long a)
  • int addExact(int x, int y)
  • long addExact(long x, long y)
  • int subtractExact(int x, int y)
  • long subtractExact(long x, long y)
  • int multiplyExact(int x, int y)
  • long multiplyExact(long x, long y)

Все эти методы выбрасывают ошибку в случае переполнения, что во многих случаях лучше, чем просто тихое переполнение лучше уж упадёт сразу, чем где-нибудь позже с совсем другой ошибкой. Но все ли возможные случаи тут покрыты? Похоже, что нет. Например, я не вижу модуль, который хоть и в очень редком случае, но всё же может переполниться:


jshell> Math.abs(Integer.MIN_VALUE)$1 ==> -2147483648

Как же так, ведь модуль это положительное число? Это так, но дело в том, что 2147483648 просто не влезает в int, поэтому этот отдельный случай является исключением. Чтобы вот так по чистой случайности не напороться на такое, можно обезопасить себя методом Math.absExact(), который появился в Java 15:


jshell> Math.absExact(Integer.MIN_VALUE)|  Exception java.lang.ArithmeticException: Overflow to represent absolute value of Integer.MIN_VALUE|        at Math.absExact (Math.java:1392)|        at (#1:1)jshell> Math.absExact(Long.MIN_VALUE)|  Exception java.lang.ArithmeticException: Overflow to represent absolute value of Long.MIN_VALUE|        at Math.absExact (Math.java:1438)|        at (#2:1)


А знаете ли вы, сколько будет, если найти целое от деления -11 на 3? А остаток? Давайте проверим:


jshell> -11 / 3$1 ==> -3jshell> -11 % 3$2 ==> -2

Ну вроде бы логично, ведь -11 = 3 * (-3) - 2. Однако если вы выполните то же самое, например, на Python, то получите совсем иной результат:


>>> -11 / 3-4>>> -11 % 31

И этот результат тоже по-своему верный: -11 = 3 * (-4) + 1. Дело в том, что есть два способа деления целых чисел: с обрезанием в сторону нуля и с обрезанием в сторону минус бесконечности. Java выбрала первый способ, Python второй. Ну а что делать, если я хочу в Java делить по-питоновски? Для этого в Java 9 появились методы Math.floorDiv() и Math.floorMod():


jshell> Math.floorDiv(-11, 3)$1 ==> -4jshell> Math.floorMod(-11, 3)$2 ==> 1


Также для совсем упоротых математиков в Java 9 появились два метода Math.fma(float, float, float) и Math.fma(double, double, double), которые делают то же самое, что и a * b + c, но только точнее, потому что используют специальную отдельную инструкцию процессора:


jshell> Math.fma(2.99, 5.91, 7.1)$1 ==> 24.7709jshell> 2.99 * 5.91 + 7.1$2 ==> 24.770900000000005


9. Аннотация java.io.Serial


Появилась в: Java 14


Используете ли вы стандартную сериализацию в Java? Этот механизм далеко не идеальный и со своими недостатками, но иногда он может быть очень удобным, потому что позволяет из коробки очень просто сделать сереализацию и десериализацию Java-объектов. Рассмотрим пример:


public class Point {    private static final long serialVersionUID = 1L;    public int x;    public int y;}

Чтобы сконвертировать объект Point в массив байтов, нужно написать всего несколько строчек:


var point = new Point();point.x = 1;point.y = 2;var baos = new ByteArrayOutputStream();try (var oos = new ObjectOutputStream(baos)) {    oos.writeObject(point);}byte[] bytes = baos.toByteArray();


Очень удобно. Кстати, вы заметили ошибку в моём коде? Конечно же, я забыл реализовать интерфейс Serializable! (Я специально добавил поле serialVersionUID, чтобы отвлечь ваше внимание.)


Правильный код будет таким:


public class Point implements Serializable {    private static final long serialVersionUID = 1;    public int x;    public int y;}

И вот это как раз и есть одна из главных проблем сериализации при её использовании можно очень легко допустить ошибку: забыть Serializable, опечататься в названии поля serialVersionUID, забыть сделать его статическим и т.д. Чтобы немного обезопаситься от такого, в Java 14 ввели новую аннотацию Serial.


Этой аннотацией теперь рекомендуется помечать все поля и методы, относящиеся к механизму сериализации:


public class Point implements Serializable {    @Serial    private static final long serialVersionUID = 1;    ...}

Теперь, если будет допущена ошибка, то появится предупреждение:


public class Point {    @Serial // Annotated member is not a part of the serialization mechanism    private static final long serialVersionUID = 1;    ...}

Или:


public class Point implements Serializable {    @Serial // Annotated member is not a part of the serialization mechanism    private static final int serialVersionUID = 1;    ...}

Аннотация будет делать проверки на всех полях и методах, которые относятся к сериализации: serialVersionUID, serialPersistentFields, writeObject(), readObject() и т.д.


К сожалению, на текущий момент предупреждения хорошо работают только в IntelliJ IDEA. В компиляторе JDK 16 проверки выполняются только с включённым флагом -Xlint:serial и работают не все. Например, для двух примеров выше javac ругается только во втором случае:


> javac -Xlint:serial Point.javaPoint.java:6: warning: [serial] serialVersionUID must be of type long in class Point    private static final int serialVersionUID = 1;                             ^

Возможно, это исправят в Java 17.



10. Методы Objects: checkIndex(), checkFromIndexSize(), checkFromToIndex()


Появились в: Java 9 / Java 16


Завершим нашу статью несколькими полезными методами для проверки индексов.


Иногда приходится писать функции, принимающие в качестве входных параметров индексы или диапазоны индексов, и чтобы начать использовать эти индексы, нужно сначала убедиться, что они не выходят за границы. То есть приходится писать подобные проверки в начале методов:


private static void getAt(int index, int length) {    if (index < 0) {        throw new IllegalArgumentException("index < 0");    }    if (index >= length) {        throw new IllegalArgumentException("index >= length");    }    ...}

Если подобных функций в проекте становится уже несколько, то чтобы не повторяться, такие проверки удобнее вынести в отдельные утилитные методы:


public final class PreconditionUtils {    public static void checkIndex(int index, int length) {        if (index < 0) {            throw new IllegalArgumentException("index < 0");        }        if (index >= length) {            throw new IllegalArgumentException("index >= length");        }    }}


Но с Java 9 теперь это больше не нужно, потому что в классе Objects теперь есть стандартные методы проверок индексов.


Метод Objects.checkIndex() проверяет, что индекс находится в диапазоне [0, length):


jshell> Objects.checkIndex(-3, 10)|  Exception java.lang.IndexOutOfBoundsException: Index -3 out of bounds for length 10|        at Preconditions.outOfBounds (Preconditions.java:64)|        at Preconditions.outOfBoundsCheckIndex (Preconditions.java:70)|        at Preconditions.checkIndex (Preconditions.java:248)|        at Objects.checkIndex (Objects.java:372)|        at (#1:1)jshell> Objects.checkIndex(10, 10)|  Exception java.lang.IndexOutOfBoundsException: Index 10 out of bounds for length 10|        at Preconditions.outOfBounds (Preconditions.java:64)|        at Preconditions.outOfBoundsCheckIndex (Preconditions.java:70)|        at Preconditions.checkIndex (Preconditions.java:248)|        at Objects.checkIndex (Objects.java:372)|        at (#2:1)


Метод Objects.checkFromIndexSize() проверяет, что диапазон [fromIndex, fromIndex + size) находится в диапазоне [0, length):


jshell> Objects.checkFromIndexSize(3, 8, 10)|  Exception java.lang.IndexOutOfBoundsException: Range [3, 3 + 8) out of bounds for length 10|        at Preconditions.outOfBounds (Preconditions.java:64)|        at Preconditions.outOfBoundsCheckFromIndexSize (Preconditions.java:82)|        at Preconditions.checkFromIndexSize (Preconditions.java:343)|        at Objects.checkFromIndexSize (Objects.java:424)|        at (#3:1)jshell> Objects.checkFromIndexSize(-2, 8, 10)|  Exception java.lang.IndexOutOfBoundsException: Range [-2, -2 + 8) out of bounds for length 10|        at Preconditions.outOfBounds (Preconditions.java:64)|        at Preconditions.outOfBoundsCheckFromIndexSize (Preconditions.java:82)|        at Preconditions.checkFromIndexSize (Preconditions.java:343)|        at Objects.checkFromIndexSize (Objects.java:424)|        at (#4:1)jshell> Objects.checkFromIndexSize(3, -4, 10)|  Exception java.lang.IndexOutOfBoundsException: Range [3, 3 + -4) out of bounds for length 10|        at Preconditions.outOfBounds (Preconditions.java:64)|        at Preconditions.outOfBoundsCheckFromIndexSize (Preconditions.java:82)|        at Preconditions.checkFromIndexSize (Preconditions.java:343)|        at Objects.checkFromIndexSize (Objects.java:424)|        at (#5:1)


Наконец, метод Objects.checkFromToIndex() проверяет, что диапазон [fromIndex, toIndex) находится в диапазоне [0, length):


jshell> Objects.checkFromToIndex(3, 11, 10)|  Exception java.lang.IndexOutOfBoundsException: Range [3, 11) out of bounds for length 10|        at Preconditions.outOfBounds (Preconditions.java:64)|        at Preconditions.outOfBoundsCheckFromToIndex (Preconditions.java:76)|        at Preconditions.checkFromToIndex (Preconditions.java:295)|        at Objects.checkFromToIndex (Objects.java:398)|        at (#6:1)jshell> Objects.checkFromToIndex(-4, 8, 10)|  Exception java.lang.IndexOutOfBoundsException: Range [-4, 8) out of bounds for length 10|        at Preconditions.outOfBounds (Preconditions.java:64)|        at Preconditions.outOfBoundsCheckFromToIndex (Preconditions.java:76)|        at Preconditions.checkFromToIndex (Preconditions.java:295)|        at Objects.checkFromToIndex (Objects.java:398)|        at (#7:1)jshell> Objects.checkFromToIndex(6, 4, 10)|  Exception java.lang.IndexOutOfBoundsException: Range [6, 4) out of bounds for length 10|        at Preconditions.outOfBounds (Preconditions.java:64)|        at Preconditions.outOfBoundsCheckFromToIndex (Preconditions.java:76)|        at Preconditions.checkFromToIndex (Preconditions.java:295)|        at Objects.checkFromToIndex (Objects.java:398)|        at (#8:1)


Кроме того, в Java 16 появились перегрузки этих функций для long:




Заключение


Сегодня я рассказал про 10 интересных API, некоторые из которых появились в буквально только что вышедшей Java 16, а некоторые уже присутствуют довольно давно ещё с 9-й версии. Надеюсь, что после прочтения данной статьи вы стали более заинтересованными в миграции на последнюю версию Java. Помните, что в новых версиях Java появляются не только новые возможности, но и изменения, ломающие обратную совместимость (1, 2, 3, 4, 5, 6, 7, 8). И чем больше вы тянете с переходом с Java 8 на последнюю версию, тем сложнее вам будет осуществить этот переход.


Продолжение следует...

Подробнее..
Категории: Java , Logging , Jmh , Java15 , Java14 , Stackwalker , Java16 , Java11 , Java9 , Java8 , String , Log4j , Slf4j , Stream , Serializable

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru