Мы уже выложили на YouTube видеозаписи докладов JPoint 2018 и специально для хаба Java на Хабре сделали традиционную подборку самых лучших из них по мнению посетителей конференции.
Как обычно, наверху «младшие» доклады, в конце — с самым высоким рейтингом. Конечно, это не значит, что один доклад намного хуже другого: если изменить методику расчета, места могут легко поменяться. В реальности, мы её и изменили, теперь используется «soft quorum» вариант рейтинга, учитывающий количество присутствовавших на докладе участников. Этот подходит имеет свои минусы (например, на кейноут приходит больше людей, чем на обычный доклад, просто потому что у аудитории нет выбора), но в целом даёт более качественную картину произошедшего.
Под катом — и видеозаписи лучших докладов, и ссылки на их презентации, и короткие описания, и ссылка на полный плейлист.
Полный плейлист
Полный плейлист со всеми видео, о которых пойдет речь ниже, доступен по ссылке.
10. Linux container performance tools for JVM applications
Контейнерная революция захлестнула всех — не обошелся без этого и мир Java. Тем не менее, у Java с этим всегда были и есть некие проблемы и особенности, о которых и пойдет речь в докладе Саши Гольдштейна.
Саша — серийный создатель перформансного хардкора. В прошлом году на JPoint он сделал отличный доклад про использование Berkeley Packet Filter для JVM (отчаянно рекомендую посмотреть запись на YouTube), и это был только вопрос времени, когда он доберётся до подробного разбора контейнеризации. Мир уходит в облака и докеры, что в свою очередь приносит нам множество новых проблем. Как вы могли заметить, большинство низкоуровневых систем отладки и профилирования после их применения к контейнерам обрастают разными особенностями и косяками. Саша катком прошелся по основным сценариям (загрузке CPU, отзывчивости IO, доступу до расшаренных баз и т.п.) сквозь призму использования современных инструментов на платформе GNU/Linux, включая BCC и perf.
Эта специфика нужна далеко не всем. Это одна из причин, почему доклад оказался лишь на десятом месте — на нем присутствовало около двух сотен человек (сравните с более чем тысячью у Толкачева и Борисова), а наш алгоритм вычисления рейтинга очень чувствителен к размеру аудитории.
Для тех же, кто так или иначе связан с контейнерами, этот доклад нужно обязательно посмотреть. Сэкономит кучу времени на самостоятельный поиск всех подробностей методом полного перебора бесчисленного количества утилит и способов их использования.
Еще хочется отметить, что доклад Саши из всего топ-10 — чуть ли не самый плотный по количеству практической информации на единицу времени. Почти с каждого слайда можно скопипастить себе какие-нибудь полезные вещи. Чтобы не заниматься подробным пересказом, покажу только поверхностную структуру изложения:
- Как устроены контейнеры?
- Control groups: CPU, memory, block I/O;
- Namespaces: pid namespace, mount namespace, network namespace;
- Разница между возникающими проблемами:
- На хосте;
- В контейнере;
- Примеры проблем с решениями:
- Подключение к JVM?
- Данные о перформансе JVM?
- Демо JVM-инструментов на хосте;
- Инструменты для получения информации о ресурсах:
- sidecar для мониторинга;
- docker stats;
- systemd-cgtop;
- htop + cgroup ID;
- nsenter или docker exec;
- Демо мониторинга ресурсов контейнера;
- Профилирование CPU-контейнеров:
- perf на хосте: -G, symbol mapping, PID mapping, sharing perf map (perf-map-agent);
- Демка с флеймграфами; оос;
- perf в контейнере в непривилегированном режиме;
- honest-profiler, async-profiler, perf vs async-profiler;
- Демка async-profiler;
- BCC — инструмент для профилирования (само решает рядо проблем, но работает только на Linux 4.9+);
- Throttling;
- Другие способы мониторинга:
- cAdvisor, SysDig, New Relic, DataDog…
9. Один раз в год сады цветут: разбор семантики «exactly-once» Apache Kafka
Виктор Гамов имеет совершенно нечестное преимущество перед остальными докладчиками. Это человек, выпустивший почти две сотни выпусков подкаста Разбор Полётов, автор кучи докладов, текстов, постов и даже книги «Enterprise Web Development» издательства O'Reilly. Само присутствие Гамова делает что угодно лучше. Уверен, он мог бы с той же интонацией рассказывать не про Кафку, а про произрастание герани на подоконнике, и это всё еще было бы увлекательно.
Здесь же у нас особый случай: изначально холиворная тема про семантику «exactly once». Кафку бросились использовать все подряд в необычайных масштабах, что потребовало переработки традиционной семантики доставки сообщений. Кафке в рот палец не клади — они переобулись на ходу под правильный протокол и формат сообщений и сделали все что нужно. На протяжении доклада Виктор рассказывает, как там это устроено внутри и на что влияет.
Две новости, хорошая и плохая. Хорошая: в Кафке всё настраивается. Плохая: в Кафке всё настраивается. Чтобы жить с этим, нужно понимать, как это работает и куда лезть своими грязными руками.
От Виктора можно было бы ожидать какого-то смузи, но тут получился отчаянный хардкор, и план примерно такой:
- Введение в Кафку:
- Топики
- Партиции
- Логи и оффсеты
- Реплики и лидеры
- Клиенты: продюсеры и консюмеры
- Продюсер
- Как работает на примерах
- Протокол продюсера
- Консюмер
- Как работает на примерах
- Протокол консюмера
- Модель обработки
- Прочитали, посчитали, записали
- Виды сбоев (все сломалось, зомби)
- Семантика обработки
- At-least-once, at-most-once, exactly-once
- Cемантика «exactly once»
- С примерами
- Слабости
- небезопасные повторы
- неатомарная запись со смещением
- зомби
- Чиним первую слабость: идемпотентный продюсер
- Чиним вторую слабость:
- Снэпшоты Чэнди-Лэмпорта
- Принцип
- Как жить со сбоями?
- Hard: сбой во время обработки
- Soft: сбой до или во время снятия снапшота
- Транзакции в Кафке
- Два типа маркеров (COMMIT, ABORT)
- Атомарная запись на множество партиций (Включая !_consumer_offsets)
- Снэпшоты Чэнди-Лэмпорта
- Чиним третью слабость: zombie fencing
- Изоляция чтения у консюмера
- end-to-end eos
- Kafka Connect Source
- Kafka Streams
- Kafka Connect Sink
8. Боремся с "Russian Hackers" с помощью Kafka Streams и Firehose API
Опять Кафка! Опять Гамов! Да ещё и с Барухом Садогурским (jbaruch) теперь. Тем не менее, этот доклад — не смузи, а вполне конкретная практическая штука о том, как на платформе Bintray (богом которой является Барух) с помощью Apache Kafka (за которую отвечает Виктор) и Firehose анализировать поведенческие паттерны, обрабатывать большие объемы данных.
Если у предыдущего доклада про внутренности Кафки было 245 слайдов, то у этого их всего 17. Это потому, что его нужно смотреть! Это в первую очередь живой диалог между ведущими и живые демки. Не задерживаемся, открываем видосик и смотрим.
7. Аппаратная транзакционная память в Java
Никита Коваль (ndkoval) — исследователь в JetBrains в команде Kotlin и PhD студент в IST Austria (на момент доклада он был в Devexperts). Его доклад сильно контрастирует с "русскими хакерами", потому что это не легкое развлекательное чтиво, а рассказ про сложные внутренности VM. Если взглянуть на слайды, можно обнаружить 150 листов, значительная часть которых — код.
Если вы были на JBreak в начале 2018 года, то могли застать рассказ Никиты о совершенно других вещах — о написании быстрой многопоточной хэш-таблицы с использованием мощи современных многоядерных архитектур и специальных алгоритмов. Согласитесь, у Никиты есть стиль. Мне сразу вспоминается Шипилёв.
В этот раз речь пойдёт про транзакционную память, которая понемногу появляется в современных процессорах, но которую пока непонятно как использовать обычному человеку из JVM-мира. Вне JVM, конечно, все проще. Но представь себе, как ты говоришь обычному Spring веб-разработчику: "Да просто редактируешь vmstructs, наваливаешь своих интринсиков, пересобираешь OpenJDK и готово!" А он такой: "Ну конечно, каждый день так делаю!". Никита как раз очень внятно рассказывает про способы использования, какие оптимизации уже есть в OpenJDK и как выполнять транзакции напрямую из Java-кода.
- Введение: почему нам нужна многопоточность
- Подходы к построению алгоритмов
- Грубая блокировка
- Тонкая блокировка
- Неблокирующая синхронизация
- Все три вида иллюстрируются на задаче-примере про игрушечный банк
- Многопоточность — это сложно. Что делать?
- Транзакции в идеальном мире. Просто пиши atomic!
- Откуда взять atomic:
- Software Transactional Memory (STM). Scala STM, NOrec, корутины.
- Hardware Transactional Memory (HTM). Haswell, Power 8.
- Hybrid Transactional Memory
- Intel RTM на примерах
- XBEGIN, XEND, XABORT, XTEST
- Intel RTM + Java
- Lock elision
- java.util.concurrent.RTMSupport
- Intrinsics: interpreter, C1, C2
- Coarse-grained / Lock-free + RTMSupport на графиках
6. Профилируем с точностью до микросекунд и инструкций процессора
Сергей Мельников (RainM) из Райффайзенбанка привез нам второй доклад по профилированию. Интересно, что до того, как заняться low-latency кодом на Java, он работал в Intel инженером по производительности компиляторов для языков C/C++/FORTRAN. В этом докладе тоже есть perf! :-) Ещё там про аппаратные особенности процессоров и технологии Intel Processor Trace, которая позволяет сделать следующий шаг в точности профилирования и реконструировать выполнение участка программы. Таких докладов довольно мало (например, можно найти доклад Andi Kleen на Tracing Summit 2015), они обычно оставляют море вопросов и не блещут практичностью применительно к Java. Здесь же у нас не просто есть человек, побывавший в обоих мирах (и Intel, и Java в банке), но еще и умеющий понятно объяснять сложные темы.
- Что это и зачем нужно
- Предметная область — low latency приложения
- Пример Московской биржи
- Выбираем профилировщик
- Как профилировать? Сэмплирующие и инструментирующие профилировщики
- async-profiler
- Учим профилировщик собирать подробный профиль
- Как запускать perf
- Как смотреть в профиль, в call stack
- perf-map-agent, sysctl, dmesg…
- Используем события PMU/PEBS в perf
- Intel Processor Trace – что это такое и как профилировать Java
- Требования: пакеты, железо, операционная система
- Как запускать на Skylake-X (Xeon и i9)
5. VMStructs: зачем приложению знать о внутренностях JVM
Андрей (apangin) — это человек, раз за разом собирающий самые глубокие и мощные доклады. На прошлом Joker у него собралось чуть меньше тысячи человек — это рекорд по объему аудитории на обычном докладе, не являющимся кейноутом. В этом ему помогает десятилетний опыт работы над виртуальными машинами и умение объяснять технический хардкор так, чтобы его можно было повторить на практике.
Многим не совсем понятно, зачем копаться в виртуальной машине, если у тебя обычное приложение на томкате, с базой данных и все как положено. В этом докладе имеется хорошая аргументация на уровне "как понять, какой запрос потянет много данных?" Если попробовать проинструментировать код с помощью JMX, то с перформансом начинает твориться что-то странное. Во-первых, можно понять, почему так происходит, во-вторых — что с этим можно сделать. На мой взгляд, этот доклад ценен не столько набором инструментов (хотя там и есть немного про helfy), сколько демонстрацией правильного майндсета разработчика OpenJDK и того, как себя надо вести в сложных ситуациях. Проговаривается наличие и объясняется смысл конкретных вещей вроде TLAB, Code Cache, Constant Pool и т.п.
4. Корутины в Kotlin
Только ленивый не знает сейчас о Kotlin, а ты, читатель, раз дочитал до четвертого пункта — явно не из ленивых. Роман (elizarov) — в прошлом разработчик высокопроизводительного трейдингового софта, а сейчас — тимлид в библиотеках Kotlin. Мы уже делали с Ромой интервью про корутины, и его, возможно, стоит перечитать до или после просмотра доклада. Корутины — очень старая концепция, еще со времен Симулы, но далеко не все мэйнстримные языки их поддерживают, в Java они появятся нескоро. А вот в Kotlin они уже есть в стабильной версии.
Этот доклад отвечает на все актуальные вопросы про корутины, то есть на все актуальные вопросы современности вообще :-)
- Общая картина развития языков
- Асинхронное программирование с коллбэками
- Futures/Promises/Rx
- Корутины в Kotlin
- regular loops, exception handling, higher-order functions
- custom higher-order functions
- все выглядит как в блокирующем коде!
- Как это работает?
- suspending functions, code with suspension points
- Интеграции
- Retrofit async
- Коллбэки и континуации (call/cc из Scheme!)
- contlinx-coroutines-core
- jdk, guava, nio, reactor, rx1, rx2
- Как запускать корутины?
- async / await
- Почему в Kotlin нет ключевого слова await?
- Concurrency — это сложно. Нужно делать это в явном виде.
- Подход Kotlin к async
- Концепция корутин: очень легкие треды
- Интероп с Java
- Синхронные корутины — generate/yield
- Пример с числами Фибоначчи
- Communicating Sequential Processes (CSP)
- Library vs Language
- Ядро языка должно быть небольшим!
- Keywords: async/await, generate/yield
- Modifiers: suspend
- kotlinx-coroutines: launch, async, runBlocking, future, delay, Job, Deferred, ...
3. На плечах гигантов: языки, у которых учился Kotlin
Доклад про Kotlin от одного из создателей языка — что еще нужно для счастья? Суть и структура изложения совершенно не такая, как у предыдущего доклада Елизарова. Роман рассказывал про конкретные вещи — что, как и почему в дизайне корутин, и как это использовать, и это нужно мне для улучшения скилла программирования на Kotlin. Здесь же Андрей (abreslav) рассказывает вещи, которые улучшают эрудицию вообще по жизни и дают понимание своего места в мире. Если вы своими глазами видели все эти языки — Java, C#, Scala, Groovy, Python, Gosu — это еще интересней, потому что появляется повод для дискуссии (посетители конференции, вероятно, могли воспользоваться случаем и действительно обсудить свое понимание вещей вживую в дискуссионной зоне). Это такое «семь языков за семь недель», но только за один час.
Кстати, недавно мы делали с Андреем отдельное интервью, но оно не только про Kotlin, а про множество разных вещей.
2. Приключения Сеньора Холмса и Джуниора Ватсона в мире разработки ПО
Делать доклады, в которых участвует более одного докладчика — это необычайно сложно. Зачастую это выглядит так: половину времени один из них стоит на сцене и скучает, и выглядит это весьма уныло. Что можно сказать про совместное выступление Баруха Садогурского и Евгения Борисова (EvgenyBorisov) — оно, напротив, сделано великолепно, это произведение искусства. Звезды сошлись в правильном порядке, и на сцене оказались два топовых спикера с огромным опытом и практикой ведения парных докладов с целью обсудить интересную им обоим тему. Почему я так это подчеркиваю — обычно зрители понятия не имеют, чего стоит создание такого представления, и воспринимают всё как должное.
Но результат оправдал вложенные силы. Посудите сами, это вечерний кейноут, самый-самый последний доклад конференции, во время которого люди уже максимально вымотаны двумя днями жести, им хочется спать, кому-то прямо сейчас нужно улетать домой и так далее. И тем не менее, в зале осталось более 600 человек точно.
Это не доклад-справочник, а доклад-шоу, его нужно смотреть. В нем Холмс и Ватсон раскроют несколько загадок, с которыми вы сталкивались, сталкиваетесь или будете сталкиваться при каждодневной разработке. Кишок сборщиков мусора и байткода не будет, зато будут инструменты, библиотеки и фреймворки, которые озадачивают рядовых разработчиков в каждодневной рутине, приводят к простою, профукиванию дедлайнов и затяжным депрессиям. Практически, в этом докладе Шерлок и Ватсон спасают ваш лоб от фейспалмов и граблей, на которые кто-то уже наступал.
Поэтому краткого содержания здесь опять не будет — просто запускайте видео и смотрите.
1. Boot yourself, Spring is coming
Барух + Гамов, Барух + Борисов, кого не хватает среди авторов популярных парных докладов? Правильно, Борисов + Толкачев (tolkkv). Еще один крутейший доклад, который, не являясь кейноутом, собрал рекордное количество участников — больше тысячи. Материала оказалось настолько много, и он такой интересный, что на него выделили целых два слота в программе конференции — а вам на YouTube придется, соответственно, отсмотреть целых два видео.
Много лет назад Java-программисты пользовались «new» для создания сервисов. Они проделывали огромное количество ручных действий и смешивали конфигурацию с бизнес-логикой. Они даже использовали техники copy-paste. Было написано много строк убогого кода, который временами даже работал.
Потом появился Spring. С ним многое изменилось… Мы получили много «магии» из волшебного цилиндра Spring, и наш код стал более чистым, простым и поддерживаемым.
И вот появился Spring Boot. С одной стороны, он решает тысячи ранее существовавших проблем: конфликты версий, задачи конфигурации, работа с инфраструктурными бинами, проблему настройки окружения и, конечно же, запуск или деплой приложения, включая сборку jar/war-архивов. С другой стороны, Spring Boot добавил в наш волшебный цилиндр еще больше магии. В результате имеют место быть два сценария:
- Всё прекрасно работает, хотя никто не знает, как.
- Ничего не работает, и никто не знает, почему.
Этот доклад раскрывает основные секреты магии Spring Boot. Вы осознаете основные принципы и конвенции, по которым работают типичные Spring Boot-приложения. Задача Кирилла и Евгения, чтобы вся магия из цилиндра превратилась для вас в куда более прозрачный процесс и вы смогли не только получать удовольствие, когда всё работает, но и понимали суть возникающих проблем и могли решить их без привлечения скорой помощи и других служб, доступных по срочным вызовам.
Заключение
Мне понадобилось несколько дней для того, чтобы отсмотреть все видео из списка. Это было непросто, но ясно видно, что это того стоило. В реальности на конференции было куда больше докладов, и просмотр лучшей десятки из них — хорошее начало для куда более масштабного пути. Если будете тоже смотреть эти доклады — не поленитесь написать свои отзывы в комментариях на Хабре!
А тем временем уже можно приобретать билеты на следующий JPoint. Он пройдет 5-6 апреля 2019 в Конгресс-центре ЦМТ. До первого января все ещё есть возможность приобрести билеты по низким ценам!