Java: fill the gaps

О простоте. Недавно один подписчик написал "канал топ, но зачем ты его ведёшь?". Вопрос понятный: хорошие посты действительно отнимают много времени и сил. Когда я была джуниором и мидлом, мне не хватало ясности. По каждой теме приходилось читать тонны документации и фильтровать огромное количество мусора. Хотелось узнать, что имел в виду автор, и как это использовать на практике. Когда в целом понятно, но вопросы "почему" и "зачем так сложно" повисают в воздухе. Быть разработчиком - значит держать в голове тысячи абстракций и десяток технологий. И это количество только растёт. Поэтому в обучении хорошо заходят принципы хорошего кода: KISS, читаемость, инкапсуляция. Любая тема раскладывается на простые шаги: 1-2-3. Некоторые темы выглядят как 1-2-3-...-99-100, но каждый шаг логичен и понятен. Этот подход я применяю в постах и в своём любимом курсе по многопоточке. Возьмём последний набор постов про лямбды. Пришлось перерыть кучу материалов, чтобы понять основную идею. Она в итоге оказалась несложной, но как долго пришлось добираться до сути! За простыми вещами всегда стоит много работы. Чтобы другие люди оценили её, используются сложные описания. Так в резюме появляется "комплексный рефакторинг ключевого компонента системы интеграции аналитики". Но чем проще, тем лучше для всех. Я стараюсь писать посты чётко, понятно и без воды. Радуюсь, когда получаю сообщения с благодарностью, что кто-то наконец увидел суть. Горжусь своим курсом по java.util.concurrent. У последнего потока доходимость около 80%. У других попсовых IT курсов редко превышает 10%. Чувствую, что сделала что-то на порядок выше рынка. Рада, что такой подход откликается подписчикам и ученикам. Спасибо, что разделяете идею о простоте, стремитесь понимать технологии лучше и хорошо делать свою работу. Спасибо, что читаете❤️

Как устроены лямбды: собираем всё вместе (4/4) В последней части наконец-то перейдём к лямбда-выражениям. Что нам уже известно: 🔸 Лямбды не приводят к созданию анонимных классов 🔸 В java 7 появились invokedynamic и MethodHandle API для поддержки динамических языков. Но эти штуки отлично подошли для некоторых java фич, в том числе лямбда-выражений. Если не читали - прочитайте, тогда этот пост будет понятней. Итак, разработчик пишет код с лямбда-выражением

stream().filter(x -> x<3)

В байткоде на месте вызова лямбды появляется инструкция

invokedynamic #2, 0

Следуем по указателям из Constant Pool и попадаем в секцию бутстрап-методов. Видим там вызов LambdaMetafactory.metafactory(…) Этот фабричный метод возвращает объект CallSite, внутри которого спрятался MethodHandle. Больше в байткоде нет информации. Понятно, что работа с лямдой - это какое-то перенаправление, а вся магия описана в классе LambdaMetafactory. Класс лежит в JDK, идём туда и видим: 1️⃣ С помощью ASM библиотечки создаётся внутренний класс. Он реализует интерфейс Predicate и называется как-то так:

class Smth$$Lambda$14/0x0000000800c02460

Класс динамический и существует только в памяти. 2️⃣ Создаётся объект этого класса и привязывается к MethodHandle внутри ConstantCallSite. 3️⃣ Все обращения к лямбде переадресуется этому объекту. ❓Чем это лучше анонимных классов? ✅ Класс создаётся и загружается динамически. Кажется, что это долго и сложно, но на деле получается быстрее, чем загрузка файла с диска ✅ Есть кэширование ✅ Новый класс наравне со всеми участвует в JIT оптимизациях ❓Почему нельзя вынести лямбду в отдельный метод и просто вызывать его? Чтобы встроить решение в остальной java код. Если в коде пишется

Predicate p = i -> x<3;

То ожидается, что p - это объект. Его можно куда-то передать и вызвать его методы. Логика вроде "назовём это объектом, но на самом деле это метод" - это слишком большое усложнение. Так не работает. Новые фичи должны вписываться в систему, а не обходить её. ❓Зачем столько переадресаций? Почему из бутстрап метода надо идти в другой класс? Нельзя было сделать встроенную инструкцию? Текущий код LambdaMetaFactory со временем изменится. Добавится больше кэширования, семантика лямбд расширится в следующих версиях java. Если вся логика описана в JDK, то гораздо легче поддерживать совместимость версий. Такая вот эпопея. Я весь процесс поняла не с первого раза и даже не со второго. Поэтому решила провести вас маленькими шажками, и описать всё максимально просто.

Как устроены лямбды: invokedynamic (3/4) 10 лет назад в java было 4 байткод инструкции для вызова методов. В Java 7 добавили invokedynamic для поддержки динамических языков. invokedynamic - это лишь небольшая часть Da Vinci Machine Project. У проекта очень красивое описание: a multi-language renaissance for the Java Virtual Machine architecture Среди других фич Interface injection, Lightweight bytecode loading, Tail calls and tail recursion и прочие интересные штуки. Но вернёмся к invokedynamic. Разберём по шагам, как он работает: 1️⃣ JVM встречает в class файле такой байткод

invokedynamic #7, 0

2️⃣ В пуле констант находим такую запись

#7 = InvokeDynamic #0:#8

3️⃣ Идём по ссылкам и попадаем в специальную секцию .class файла под названием BootstrapMethods. Если компилятор использует invokedynamic, то он обязан прописать такой метод. 4️⃣ Там мы находим набор инструкций, который по заданным аргументам укажет на конкретный метод. В итоге всё сводится к получению и вызову MethodHandle. В чём фишка: В других invoke* алгоритм связывания жёстко задан внутри JVM, а для invokedynamic логика связывания прописывается в отдельном методе, который может быть любым. Такая вот общая схема. Дальше идут оптимизации. Например, бутстрап метод возвращает не сам MethodHandle, а более гибкий CallSite. У него три реализации: одна с неизменным MethodHandle и две с переменным invokedynamic был создан для поддержки динамических языков. Но стало понятно, что с ним можно реализовать много классных фич в самой java. Так что на следующей неделе соберём всё вместе и погрузимся в детали реализации лямбда-выражений🤓

Как устроены лямбды: вызов методов внутри JVM (2/4) Одним летним утром мы обсудили Method Handle API. А в первом осеннем посте сделаем полшага назад и посмотрим, как вызываются методы в JVM. Эта история тоже непростая, поэтому начнём с древних времён java 6. Для разных методов компилятор генерирует разные байткод инструкции: 🍂 invokespecial - приватные методы, конструкторы и вызовы через super 🍂 invokestatic - статические методы 🍂 invokevirtual - public и protected методы 🍂 invokeinterface - вызов методов интерфейса Байткод можно посмотреть, вызвав команду для скомпилированного файла:

javap -c -v UserInfo.class

При первом использовании файл с байткодом загружается с диска и регистрируется внутри JVM. Нам интересны четыре сущности: 1️⃣ ConstantPool - табличка из class-файла с именами полей, методов и аргументов. Выглядит как-то так:

#14=Utf8        Autumn
#16=Class       #18           
#17=NameAndType #19:#20 

2️⃣ Список байткод инструкций

29: getstatic     #39 
32: aload_3
33: invokevirtual #45

Все конкретные методы и аргументы обозначаются через ссылки из Constant Pool. 3️⃣ Табличка виртуальных методов для класса 4️⃣ Табличка с интерфейсами и реализациями Таблицы 3 и 4 лежат внутри JVM в особой структуре, чтобы по ним было легко перемещаться. Каждый из invoke* методов работает по своему алгоритму. Понятно, что для protected метода нужно походить по иерархии, а для приватного это не нужно. Что тут важно: все структуры строятся при загрузке класса и больше не меняются. В Java 7 в JVM добавилась инструкция invokedynamic для поддержки динамических языков. Зачем в JVM поддержка других языков? А потому что JVM - очень развитая и крутая: 🍁 Кроссплатформенность - берёт на себя работу с операционной системой и даёт заняться чистейшим программированием 🍁 Изоляция - можно безопасно запускать несколько приложений 🍁 JIT компиляторы 🍁 Поддержка многопоточности, сборщики мусора, рефлекшн Думаете, у всех такое есть? А вот и нет. Но есть один недостаток. JVM совершенно не приспособлена под динамические языки - JavaScript, Python, Ruby. Все invoke* методы должны заранее знать все классы и типы аргументов. Поэтому в JVM добавили новую инструкцию invokedynamic. А о том, как она работает, поговорим в пятницу.

Method Handle: краткий обзор В java 7 появилось новое апи для вызова методов - MethodHandle. В этом посте обсудим его составные части, разницу с Reflection, и где MethodHandle может пригодится. В чём разница с Reflection API? MethodHandle выполняет проверки типов, доступов и тд всего один раз - во время создания. Собственно для этого метод хэндл и создавался - оптимизировать вызов методов, неизвестных во время компиляции. Reflection делает все операции при каждом вызове. Чем больше вызовов - тем сильнее разница. В OpenJDK даже есть JEP "Переписать реализацию Reflection API на MethodHandle", что говорит о многом. Как им пользоваться? 1️⃣ Получаем фабрику для будущих метод хэндлов

Lookup pl = MethodHandles.publicLookup();

2️⃣ Задаём сигнатуру метода

MethodType mt = MethodType.methodType(String.class, Integer.class, Long.class);

Первый аргумент (String.class) - это возвращаемое значение, остальные - входные параметры. 3️⃣ Получаем указатель на метод

MethodHandle mh = all.findVirtual(User.class, "findName", mt);

Это ссылка на метод findName в классе User, который принимает на вход два параметра и возвращает String. 4️⃣ Подставляем аргументы и вызываем

String res = mh.invoke(1, 2L);

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

LoggerFactory.getLogger(AccountService.class);

Эта строка копируется из класса в класс, меняется только имя в скобках. Операция настолько простая, что можно забыть это сделать🙂 Если использовать MethodHandle:

Logger.getLogger(MethodHandles.lookup().lookupClass());

то можно спокойно копировать строчку и ничего не менять. В целом основная миссия MethodHandle - работать в паре с invokedynamic. Но об этом чуть позже🙂

Как НЕ реализованы лямбда-выражения Давно хотела написать о том, как выглядят лямбды внутри JVM. Во-первых, мало кто об этом знает. Есть несколько статей и видео с конференций, но они достаточно сложные. Во-вторых, это интересно. Для ответа на вопрос нужно представлять, как работает JVM и собрать вместе несколько концептов. В-третьих, время не стоит на месте. Java развивается, а многие до сих пор не в курсе изменений 10летней давности. Как устроены лямбды - вопрос непростой, поэтому будем идти небольшими шагами. В этом посте посмотрим на возможные реализации лямбд и обсудим, что с ними не так. Часть 1: внешний вид. Как лямбды будут выглядеть в коде? Первая догадка - использовать опыт других языков и ввести в JVM тип function:

fun(s: Integer): boolean { return s<3; }

Легко для понимания, сложно для реализации. Java - ООП язык, всё в JVM заточено под работу объектов и примитивов. Добавить новый тип данных - чудовищно огромная работа. Как функция будет хранится, вызываться и взаимодействовать с другими объектами? Будет ли она работать с дженериками? Тысячи вопросов и сложностей. Второй вариант: пусть лямбда реализует интерфейс с одним методом:

Predicate p = i -> i<3;

Выглядит по-джавовски и отлично впишется в текущую систему. Существующие библиотеки будут работать с лямбдами по умолчанию. Но какой объект будет присвоен переменной p? Часть 2: реализация Здесь тоже два варианта. Первый - сделать внутренний класс с одним методом и создать его экземпляр. ✅ Простая реализация ❌ Придётся компилировать и загружать класс для каждой лямбды, а при каждом вызове создавать новый объект. С учётом того, что лямбды станут основой Stream API и использоваться для обработки данных - решение ужасное и непроизводительное. Второй вариант - компилировать код лямбды в отдельный метод и подставлять в исходный код MethodHandle. Мы рассмотрим MethodHandle на следующей неделе, но если кратко - это указатель на метод. Компилируем исходный пример в:

public boolean lambda(Integer i) { return i<3; }
MethodHandle mh = LDC["lambda"];

И подставляем mh в исходный код:

...stream().filter(mh)...

В теории решение отличное, на практике - неподходящее. ❌ Теряется информация о входных и выходных типах, приходится проверять их в рантайме ❌ Библиотечные методы не принимают на вход MethodHandle Как же сделаны лямбды? Об этом поговорим на следующей неделе: ▫️ Сначала вернёмся во времена java 6 и посмотрим как вызываются методы в JVM ▫️ Изучим новую байткод инструкцию java 7 и чуть глубже обсудим MethodHandle После этого говорить про лямбды будет легко и понятно.

Лямбды и разрыв шаблона Лямбда-выражение - анонимная функция, которую можно передавать в методы как параметр:

Function<Integer,Integer> sum = (a,b) → a+b;

В чём преимущество лямбда-выражений? Очевидный ответ - в краткости. Раньше чтобы "передать поведение" нужен был отдельный или анонимный класс, а теперь есть переменная с анонимной функцией. Удобно и понятно. Но у лямбд есть ещё одно интересное свойство. Посмотрим на него на примере обхода коллекций. В далёкие времена обойти коллекцию можно было двумя способами: ▫️С помощью цикла ▫️Через итератор Этот подход называется external iteration или внешний обход. Последовательно идём по элементам коллекции и применяем к ним некоторую логику. С коллекцией общаемся через интерфейс. Главный путь оптимизации - оптимизация логики обработки. Лямбда-выражения поменяли сценарий работы. Теперь мы как бы передаём функцию внутрь структуры данных. Структура данных сама решает, как применить функцию исходя из деталей своей реализации. Теперь уже логика обработки скрыта за функциональным интерфейсом, а структура данных ей пользуется. Это называется internal iteration или внутренний обход. Итого у нас разрыв шаблона. Двадцать лет обход коллекций шёл по сценарию 🔸Логика обработки - ведущий игрок, все оптимизации здесь 🔸Структура данных - абстракция, скрыта за интерфейсом С появлением лямбда выражений и Stream API субъект и объект поменялись местами: 🔹Логика обработки доступна через интерфейс 🔹Структура данных - главная, оптимизации происходят на этом уровне Теперь работу над коллекцией легко делить между потоками. Раньше это было невозможно - логика обработки могла быть любой и параллелить в каждом случае нужно по-разному. Деление на подзадачи на уровне структуры данных гораздо проще, и теперь у нас есть библиотечный метод parallel() в Stream API. Понятно, что такой подход применим не только к обходу элементов в коллекции, но и к взаимодействию любых компонентов в целом. Смена ролей часто приводит к свежему взгляду на привычные действия. И в жизни, и в написании кода🙂

IDEA training Я часто пишу посты про фичи Intellij IDEA, и такие посты всегда пользуются бешеной популярностью. IDEA классная, но мало кто знает обо всех возможностях. Я уже писала, как выучить полезные именно вам шорткаты через Productivity Guide или плагин Key Promoter X. Более основательный способ - это плагин IDE Features Trainer. Это целый мини-курс, который охватывает написание кода, рефакторинг, навигацию и тд. Для каждой темы открывается учебный проект, и вам по шагам рассказывают, что и куда нажимать🥰 Как поставить: File → Settings → Plugins → MarketPlace → IDE Features Trainer → Install Потом идёте в Help → IDE Features Trainer и следуете инструкциям. Если вы новичок или редко пользуетесь горячими клавишами, но очень хотите начать, то это лучший вариант🔥

Надо ли добавлять джуна в ревьюеры? Во многих командах такой вопрос даже не стоит. Понятно, что новичок ▪️ мало разбирается в предметной области ▪️ плохо ориентируется в коде проекта А значит ничего не поймёт, ничего не скажет, и нет смысла его добавлять в ревьюеры. Даже если вы сеньор, дать джуниору посмотреть пул-реквест - хорошая идея. И тому есть четыре причины: 1️⃣ Проверка читаемости Применяете SOLID, следуете принципам clean code, но понять вас способен только разработчик с 10-летним опытом? Что-то тут не так🙂 Возможно вы пишете запутанную дичь в стиле 2000-х, пул-реквест занимает 50 файлов, вы вышли за пределы задачи и заодно провернули сложный рефакторинг. Это сильно усложняет понимание кода. Но коллеги-сеньоры привыкли к вашему стилю, поэтому не жалуются. А вот если изменения понятны даже новичку, значит вы написали действительно читаемый и понятный код. Чтобы помочь начинающим ревьюерам, напишите саммари пул-реквеста. 3-5 предложений: в чём задача, главная проблема и суть решения. 2️⃣ Быстрее получаете фидбэк Не только джуниоры, но и другие коллеги быстрее поймут контекст и суть изменений. Быстрее дадут фидбэк или поставят аппрув. 3️⃣ Многоуровневый фидбэк Каждый сделает ваш код лучше: 🔸 Джуниор заметит опечатку в названии переменной 🔸 Мидл подскажет удобный метод из java 11 🔸 Сеньор укажет на непокрытый кейс 🔸 Тимлид заметит несоответствие корпоративным стандартам 4️⃣ Обмен знаниями Материалы в разделе онбординга устаревают. Пул-реквесты показывают то, что происходит здесь и сейчас. Код-ревью быстро вводит нового сотрудника в курс дела: 🔹 Над чем вообще работает команда 🔹 Как писать код и как его оформлять 🔹 Какие тесты и в каком объёме писать 🔹 Как работать с БД и накатывать апдейты 🔹 Что обновлять в документации и CI Чем быстрее новички вольются в проект, тем быстрее возьмут на себя ваши задачки.

Разница между for и forEach довольно проста. for использует для обхода итератор, а forEach - траверс. В этом посте разберём разницу между ними. Цель — чисто познавательная: как компьютер саенс проявляется в языке программирования. Сразу скажу: всё это имеет смысл только для обхода многопоточных структур данных. Если мы попробуем изменить ArrayList, HashMap и т.д во время обхода, то получим ConcurrentModificationException. Начнём издалека и посмотрим на обход более сложной сущности — графа. Граф состоит из вершин и рёбер, в нём могут быть циклы. Обойти все вершины графа по одному разу (найти гамильтонов путь) — непростая задача. Алгоритм ведёт учёт посещённых вершин и перебирает множество вариантов. В computer science обход структуры данных называется traverse. 🔸Самое важное: следующий элемент вычисляется только, когда понадобится. Вернёмся в мир java. В стандартных структурах царят списки, множества, очереди и деревья. Циклов здесь нет, следующий элемент при обходе однозначен, а его отсутствие означает конец работы. Поэтому обход выглядит так:

Iterator it=list.iterator();
while(it.hasNext())
  int result = it.next();

Метод next возвращает текущий элемент и сдвигает указатель на следующий. Метод hasNext проверяет, ссылается ли этот указатель куда-нибудь. Этот паттерн повторяется снова и снова и называется Iteration. Итератор лежит в основе синтаксиса for (T e: collection) 🔸Самое важное: указатель на следующий элемент вычисляется заранее. Возможный минус: если мы удалили или поменяли элемент, который должен вывестись следующим, то итератор не подхватит изменений и выведет старое значение. Что по задаче: Обход через for использует итератор. Указатель на следующий элемент вычисляется заранее. Более подходящий новый элемент не отображается, и выводится 2 элемента. Метод forEach использует траверс и вычисляет следующий элемент только когда он запрашивается. Поэтому новый ключ подхватывается, и в консоль попадают 3 элемента. ❓Почему нельзя использовать траверс по умолчанию? — Итератор проще и работает быстрее, а условия для пропуска элемента при обходе встречаются редко. ❓Зачем нужно несколько вариантов? — ConcurrentHashMap может перестраиваться во время обхода. Чтобы во время перестройки не выводить дубликаты, используется траверс со сложной логикой. Итого: при выводе элементов ConcurrentHashMap через for и forEach используются разные алгоритмы обхода, поэтому результат вывода тоже разный. ❗️Для однопоточных коллекций между for и forEach нет никакой разницы, в обоих случаях используется итератор.

​Теперь заменим for на forEach. Сколько элементов выведется в консоль?

​Сколько элементов выведется в консоль?

Почему в java нет Elvis оператора? Элвис оператор ?: — популярная конструкция, которая используется в Groovy, Kotlin, C# и других языках, но не в java. В этом посте мы обсудим, почему так получилось и чем java отличается от Kotlin. Часть 1: обзор операторов Элвис оператор ?: используется следующим образом:

String src = …
String x = src ?: "default";

▫️Если

src равен null, то x = "default" ▫️Если src НЕ равен null, то x = src По сути это сокращённая форма тернарного оператора:

String x = src==null ? src : "default"

Есть два оператора, которые похожи на элвис: 🔸 ?. (с точкой) — null-safe member selection operator

str?.toString()

= если str не равен null, то вызвать метод toString() 🔸 ?[] — null-safe array access

lines?[6]

= если массив lines существует, то прочитать 6 элемент Все операторы неплохо соединяются между собой:

String aMember = g?.members?[0]?.name ?: "nobody";

Но элвис оператор это только ?: В java таких конструкций нет. Иногда это используют как аргумент того, что джава неудобная и несовременная. На самом деле элвис оператор мог появиться уже в java 7. Пользователи java 5 называли элвис самой ожидаемой фичей. Но он не попал в итоговый релиз. Давайте разберём, почему в java элвис оператор так и не появился, а в котлине, другом JVM языке, он есть. Часть 2: зачем нужен null Цель элвис оператора — облегчить работу с null. Значение null в джава коде выступает в двух ролях: 1️⃣ Ожидаемое значение и часть бизнес-логики Поле необязательное или ещё не готово. Разработчик знает об этом заранее и учитывает в коде. Элвис оператор прекрасно подходит для этого сценария. 2️⃣ Индикатор ошибки Что-то пошло не так: пропущен обязательный параметр, соединение с БД оборвалось, инициализация не завершилась. Получаем NullPointerException, разбираемся с причинами и устраняем ошибку. Здесь элвис оператор замаскирует проблему и сделает только хуже. Ошибка прикроется значением по умолчанию и пройдёт мимо нас. Часть 3: Kotlin Котлин использует другой подход: по умолчанию переменные НЕ могут быть null. Свойство nullability задаётся явно — через вопросик:

var str: String? = "abc"

Все null значения под чётким контролем. Поэтому элвис оператор не скрывает ошибок, а помогает писать лаконичный код. Захотели nullability — чётко это обозначили. Хотим избавиться от этого свойства — используем элвис оператор. Часть 4: Optional В java 8 появился способ явно указать, что значение может быть пустым — класс Optional. Метод orElse выполняет функции элвис оператора: если внутри Optional ничего нет, то возвращается значение внутри orElse. Итог Во времена java 5 ситуация была сложной: null мог означать и ошибку, и нормальное значение. Чтобы не провоцировать скрытые ошибки, комьюнити отклонило добавление элвис оператора. После появления Optional нулл в коде почти всегда указывает на ошибку. Использовать элвис оператор в такой ситуации - нецелесообразно, поэтому маловероятно, что он появится в будущих версиях java.

​Брейкпойнты в Intellij IDEA Большинство разработчиков пользуются только базовым дебагом в IDEA: щёлкнуть рядом с номером строки, чтобы добавить или удалить брейкпойнт. Чтобы отладка стала быстрой и приятной, ловите 4 классные фичи: 1️⃣ Условия остановки Если метод часто вызывается, или брейкпойнт стоит в цикле, не тратьте время на ожидание нужных значений: 🔹Правый щелчок по брейкпойнту 🔹Добавить в Condition условие остановки — можно использовать все доступные переменные, объекты и методы 2️⃣ Изменение параметров в динамике Чтобы посмотреть, как меняются переменные, их выводят в консоль через System.out.println. Более продвинутый вариант: 🔸Зажать Shift и добавить брейкпойнт 🔸Щёлкнуть галочку Evaluate and log 🔸Вписать нужное выражение Отладчик не будет останавливать выполнение, а запишет в консоль значение выражения. Незаменимая фича для отладки многопоточных приложений, кода сторонних библиотек и удалённого дебага! 3️⃣ Отключение брейкпойнта Ненужный брейкпойнт можно не удалять, а отключить: ▪️Щёлкнуть колёсиком по брейкпойнту ИЛИ ▪️Правый щёлчок по брейкпойнту → снять галочку с Enabled 4️⃣ Массовое удаление Когда в проекте много брейкпойнтов, IDE при дебаге немного тормозит. Чтобы удалить ненужные, откройте полный список: ▫️Правый клик по любому брейкпойнту ▫️Ссылка More ▫️Слева видим список брейкпойнтов ▫️Удаляем ненужные В этом окне ещё есть фильтры для выборочной остановки, но удобнее пользоваться условиями из первого пункта.