Java: fill the gaps

Как JVM работает со строками, часть 1 По статистике OpenJDK в приложениях 15-50% памяти занимают экземпляры String. Это много, поэтому разработчики JVM прикладывают много усилий, чтобы оптимизировать работу со строками. ❓Как сэкономить память, если в системе миллионы экземпляров? 1️⃣ Уменьшить количество памяти под одну строку. Мы уже разбирали этот случай: в java 9 вышло обновление Compact String и размер памяти под строки сократился до 2 раз. 2️⃣ Добавить кэширование. Есть два способа создать экземпляр String: 🔸Через оператор new:

String s = new String ("one");

В памяти создаётся новый объект. 🔸Без оператора new:

String s = "one";

В этом случае идёт работа с кэшем строк под названием String pool. Схема работы такая: ▫️Проверить в String Pool, есть ли там такая строка. ▫️Если есть — вернуть её. ▫️Если нет — создать объект, поместить в кэш, вернуть. ❓Как реализован String pool? Структура похожа на HashMap: хэш-таблица фиксированного размера с парами хэш — строка. В последних версиях java она занимает 64 МБ, при желании размер меняется с помощью флажка:

-XX:StringTableSize=65536

В следующем посте рассмотрим ещё два способа снижения издержек на строки. ✅ Ответ на 1 вопрос перед постом: new String("Java") создаёт новый объект в хипе, s2 = "Java" создаёт объект в String pool. Это два разных объекта, поэтому при сравнении через == результат будет false. Можно исправить ситуацию и добавить строчку в кэш методом intern():

String s1="Java";
String s2=new String("Java");
s2=s2.intern();
println(s1==s2); //true

✅Рассмотрим второй вопрос. О том, сколько строк создаётся в конструкции

String str=new String("Java");

Подвох в том, что для конструктора String нужен экземпляр String, поэтому создаётся 2 строки — "Java" и new String; Но если строка "Java" использовалась раньше и попала в кэш, то будет создана только одна строка — new String.

Подборка: Java core и Java 8 ⚙️Java core: ▫️Сборщики мусора. Плюсы и минусы G1 ▫️Как работает переопределение методов? ▫️2 способа обхода коллекций ▫️Система типов и проверка аргументов 👑 Java 8: ▪️Stream API: обзор и основные методы ▪️Stream API: ускоряемся🚀 ▪️HashMap в Java 8 ▪️Функциональные интерфейсы: обзор ▪️Функциональные интерфейсы: best practices

Подборка: Intellij IDEA Несколько приёмов для продуктивной работы: 1️⃣ Live templates: пишем код быстрее 2️⃣ Дебаг Stream API 3️⃣ Мощные брейкпойнты 4️⃣ Комментарии TODO 5️⃣ Быстрый поиск чего угодно

Подборка: подготовка к собеседованиям 🔥Рейтинг технологий в вакансиях HeadHunter🔥 Вопросы с собеседований: ▫️Сравнение переменных ▫️Как создать поток: 7 вариантов ответа ▫️Интерфейсы: поля и методы ▫️Интерфейсы: отличия от абстрактного класса ▫️Вопросы про юнит-тесты

Ребята, спасибо, что уделили время заполнению анкеты! Я получила больше сотни ответов и ценных идей, буду внедрять💪 Многие писали, что присоединились недавно, поэтому на этой неделе будут подборки самых популярных статей. Если что-то пропустили — рекомендую прочесть.

Привет! Сегодня будет не полезный пост, а небольшая просьба. Я пишу посты в этом канале уже 5 месяцев: делюсь знаниями, инструментами и аналитикой, стараюсь доступно передать свой 7-летний опыт java разработки. Постоянная обратная связь мотивирует писать дальше: меня очень радуют ваши лайки, шеры и личные сообщения. Приятно, что вы цените точную и практическую информацию и мой труд🧡 Я уже несколько месяцев занимаюсь созданием курса по многопоточности в java. В нём будет: ▫️Необходимая теоретическая часть ▫️Как и какими инструментами решать конкретные задачи ▫️Что актуально сейчас и тренды ближайших лет ▫️Разбор вопросов с собеседований Большая часть материалов готова, но я хочу убедиться, что раскрыла все важные и интересные темы. Поэтому прошу вас мне помочь и заполнить небольшую анкету: https://docs.google.com/forms/d/10zfRjnM6Fbpr03LWbNRETQDl3SNd7kjGmVh7Rh2XFRY/edit?usp=sharing

​WakaTime: лёгкий способ прокачать навык эстимации Секрет успеха прост — составить план и придерживаться его. Задача разработчика при планировании - оценить время на задачу с учётом сложности и рисков. Точные прогнозы это плюс к репутации, сорванные сроки — минус. Навык оценки легко тренировать - почаще сравнивать оценку и фактическое время выполнения. Со временем у вас разовьётся сильная интуиция и адекватная оценка своих способностей. Приятный бонус - любовь менеджеров и низкий уровень стресса😌 Самое сложное — посчитать, сколько времени по факту ушло на задачу. Можно полагаться на память, а можно трекать время автоматически. Самый популярный плагин Intellij IDEA для Git — WakaTime. В бесплатной версии недоступно почти всё, но можно смотреть: 🔸Сколько времени ушло на написание кода 🔸Сколько времени заняла каждая задача:

5h 6 mins feature/EX-45
  50 mins bugfix/EX-64

Для мониторинга своей активности этого достаточно. Полная инструкция: 1️⃣ Установить в IDEA плагин WakaTime 2️⃣ Перезапустить IDEA, появится окошко для ключа 3️⃣ Зарегистрироваться на сайте и перейти в раздел для IDEA 4️⃣ Взять из п.5 API Key, ввести его в IDE 5️⃣ Зайти в настройки, отключить все уведомления 6️⃣ Зайти в дашборд Можно трекать работу в других IDE и редакторах — Eclipse, Android Studio, GoLand, даже в Notepad++. Можно подключить к GitLab, GitHub и BitBucket и смотреть, сколько времени занял каждый коммит.

​Самый сложный вопрос. Что напечатается в консоли?

BigDecimal: зачем нужен, что внутри, и как всё не испортить Ответ на первый вопрос перед постом: false. Сумма 0.1 и 0.2 не равна 0.3. Она равна 0.30000000000000004. Запустим на Python 2.7:

print(0.1 + 0.2)
0.3

Почему python справился с примером, а java - нет? Как можно писать на java высоконагруженные приложения, если она не может сложить 0.1 и 0.2? Oracle подробно объясняет этот феномен на 80 страницах. Главная проблема в том, как десятичная часть хранится в двоичном формате. Целые числа записываются через степень двойки однозначно: 9 = 8 + 1 = 2^3 + 2^0 → 1001 Десятичная часть выражается через отрицательную степень двойки. Иногда получается нормально: 0.5 = 2^(-1) → 0.1 Иногда не очень: 0.1 = 2^(-4) + 2^(-5) + 2^(-8) + … → 0.00111101110011001100110011001 Если перевести это обратно в десятичную форму, то видно, что хранится там совсем не 0.1: 0.100000001490116119384765625 С 0.2 похожая ситуация. Поэтому результат получается искажённым. При выводе часть чисел не показывается, в консоль выводится только 0.30000000000000004. Python 2.7 использует для вычислений ту же систему, но показывает меньше знаков после запятой. Python 3 выводит больше знаков и результат похож на результат java:

print(0.1 + 0.2)
0.30000000000000004

❓Зачем использовать такую неточную систему? Если хранить целую и дробную часть одинаково, то для вычислений не нужно дополнительных преобразований. Результат считается быстро, а уровень погрешности на практике низкий. В нашем примере ошибка на 16 разрядов ниже основного значения, в большинстве случаев это ок. Для точных вычислений алгоритмы сложнее. На практике используются три основных метода: 🔸Ограниченная точность (Limited-Precision Decimal) 🔸Символьная логика (Symbolic calculations) 🔸Длинная арифметика (Arbitrary-precision decimal) Класс BigDecimal использует последний подход. Число 12.345 хранится как пара: ▫️целое значение: 12345 ▫️количество десятичных знаков: 3 За счёт этого BigDecimal хранит числа без потери точности. Целая часть хранится либо в переменной int, либо в массиве. Размер числа ограничен только количеством доступной памяти. Минусы такого подхода: ❌ Медленные вычисления ❌ Большой расход памяти ❌ Много промежуточных объектов ❌ Менее выразительный код Теперь ответ на второй вопрос перед постом: объекты BigDecimal(0.2) и BigDecimal("0.2") НЕ равны. В конструктор

BigDecimal(0.2)

передаётся примитив double, в котором вместо 0.2 лежит 0.20000000000000001110223... Поэтому объект BigDecimal будет хранить это число, а не 0.2. Это самая частая ошибка при работе с BigDecimal. Для чисел с запятой надёжнее передавать в конструктор строку.

​Что будет в консоли?

​Что будет выведено на консоль?

​Статистика: что использовали Java разработчики в 2019 году Бостонская компания Snyk каждый год опрашивает разработчиков об их проектах и технологиях. В прошлом году в опросе поучаствовало две тысячи человек, в том числе 8% участников из России. Главное из отчёта за 2019: 1️⃣ Какая версия java используется в продакшене? 64% — 8 25% — 11 3% — 7 и ниже 2️⃣ Почему Вы не переходите на последнюю версию java? 51% — И так всё устраивает 32% — Трудности с миграцией 30% — Сложно согласовать переход 3️⃣ Какой JVM язык используется в качестве основного? 87% — Java 5,5% — Kotlin 2,9% — Closure 2,6% — Scala 1,5% — Groovy 4️⃣ Вы используете разбиение на модули (фича Java 9)? 64% — Нет 29% — Планируем 7% — Да 5️⃣ Какая у Вас версия Spring в продакшене? 48% — 5.1 18% — 5.0 17% — 4.3 5% — 4.2 4% — 3.2 6️⃣ Какой серверный веб-фреймворк Вы используете? 50% — Spring Boot 31% — Spring MVC 11% — JSF 5% — Vert.x 5% — Vaadin 5% — Struts 7️⃣ Ваша основная IDE: 62% — Intellij IDEA 20% — Eclipse 10% — NetBeans 8️⃣ Ваш инструмент сборки: 64% — Maven 25% — Gradle 6% — Ant 9️⃣ Ваш CI-сервер: 58% — Jenkins 12% — Никакой 6% — GitLab 5% — TeamCity 4% — Bamboo 4% — Travis 4%— Circle 🔟 Ваш репозиторий: 24% — private GitLab 16% — public GitHub 15% — Enterprise GitHub 15% — BitBucket Server 11% — public GitLab 10% — BitBucket Cloud Полная версия отчёта тут. Очень удивило, что 12% не используют CI, и что Closure обогнал Scala. Рост популярности Intellij IDEA по сравнению с прошлым годом тоже впечатляет:

​Тестирование, часть 2. Тестовое покрытие Code coverage (CC) - метрика, которая показывает, насколько код покрыт тестами. ❓Как считается СС? Запускаются тесты и отслеживается, какие классы, методы и строки кода выполнились. Это число делится на общее количество и так получается процент кода, покрытый тестами. ❓Почему у СС плохая репутация? ❌ Не говорит о качестве тестирования и надёжности системы. Если метод выполнился, это не значит, что он протестирован. ❌ Тестировать get/set методы, конструкторы и классы-конфиги нет необходимости, но из-за жёстких требований по СС приходится писать бесполезные тесты. ❓Зачем считать СС? ✅ Менеджеры хотят быть в курсе состояния проекта и не хотят смотреть в код. Поэтому их главный инструмент - это метрики, в том числе СС. Так оценивается текущая ситуация и сравниваются релизы. ✅ Качество и надёжность— понятия субъективные. С помощью СС и последующего анализа можно найти компоненты, которые слабо покрыты тестами. Таким образом увеличить надёжность системы. ❓Какие значения СС нормальные? Для большинства проектов это 60-80%. ❓Как посчитать? 1️⃣ Intellij IDEA: Run → Run with Coverage По умолчанию IDEA использует свой способ подсчёта, но для java есть ещё 2 библиотеки: 🔸JaCoCo 🔸Emma (не поддерживается с 2013) Результаты разных библиотек могут отличаться. Если на этапе CI/CD используется JaCoCo, то лучше в IDE тоже использовать JaCoCo. Чтобы поменять: Run → Edit Configurations... → Code Coverage → Choose coverage runner 2️⃣ Во время сборки. Те же библиотеки используются в Maven и Gradle плагинах — JaCoCo Plugin, Emma Plugin. 3️⃣ На этапах CI/CD. JaCoCo Plugin и Emma Plugin доступны для Jenkins, Teamcity, GitLab, Travis и остальных CI серверов.