Разъяснение про увеличение хипа:
В 64 битной JVM существует сжатия указателей, которое контролируется опцией UseCompressedOops и включено по-умолчанию для 64 битных систем начиная с Java SE 6u23
Если размер хипа для вашей программы больше 32GB, то сжатие перестает работать и все указатели становятся размером в 8 байт (в два раза больше).
То есть, увеличивая хип с 32гб на 40гб, вы не увеличиваете фактически хип, а уменьшаете его!
Получается, что имеет смысл увеличивать с 32гб хип сразу на что-то большее 48гб.

Ссылки по теме:
На русском - https://habr.com/ru/articles/440166/
Compressed oops in the Hotspot JVM - https://wiki.openjdk.java.net/display/HotSpot/CompressedOops
How does JVM allocate objects - https://umumble.com/blogs/java/how-does-jvm-allocate-objects%3F/
CompressedOops: Introduction to compressed references in Java - https://www.javacodegeeks.com/2016/05/compressedoops-introduction-compressed-references-java.html
Trick behind JVM's compressed Oops - https://stackoverflow.com/questions/25120546/trick-behind-jvms-compressed-oops
Java HotSpot Virtual Machine Performance Enhancements - https://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html

Ответ к вопросу про разницу между interrupted() и isInterrupted() :
Метод interrupt() выставляет флаг прерывания на конкретном потоке, указывая, что ему следует остановиться. Ставит значение флага true.
Статический метод Thread.interrupted() возвращает значение флага прерывания для текущего потока. После проверки всегда присваивает значение флага false и запускает поток.
Метод isInterrupted() возвращает значение флага прерывания для того объекта, на котором вызван. Не запускает поток.

Хороший видос про то, как правильно проходить алгоритмические собеседования - https://youtu.be/gbgiFVFhGkc?si=97bIXOz0Q4M4WKD3

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

Чему равны d1,d2 ?

Что не так в этом многопоточном коде?

Основная проблема в том , что код по факту не является многопоточным, вызывается метод Feature.get(), который блокируется до тех пор, пока не отработает код внутри callable и не вернется результат, поэтому в цикле блокируется по очереди каждый вызов и следующий запускается после того, как предыдущий уже завершен. Пример того, как можно сделать код многопоточным 👆

Есть ли проблемы в этом коде?

Ответ к коду про тред пул и строки из файла
(https://t.me/java_interview_tasks/316):
В тред пуле неограниченная по размеру очередь и все таски будут складываться в эту очередь,
Так как потока всего два и разгребать они очередь будут не успевать , если строк в файле довольно много будет, то случиться OutOfMemoryError.

Здесь не будет никакой ошибки, так как стрим вообще не будет запущен из-за отсутствия терминальной операции.
Вопрос для читателей, упадет ли код с ошибкой (если да, то с какой?) если в этот стрим добавить .count() ?

Проверим мощь Virtual Threads: какой метод отработает быстрее?

# JMH version: 1.33
# VM version: JDK 21.0.1, OpenJDK 64-Bit Server VM, 21.0.1+12-29
# 16 cores

Результаты на моем ноуте:
# JMH version: 1.33
# VM version: JDK 21.0.1, OpenJDK 64-Bit Server VM, 21.0.1+12-29
# 16 cores

Benchmark Mode Cnt Score Error Units
Test.testCachedExecutorTask200ms avgt 2 214770,671 us/op
Test.testFixedExecutorTask200ms avgt 2 4260257,133 us/op
Test.testVirtualExecutorTask200ms avgt 2 212590,221 us/op

Интерпретация:
Разницы между Cached и Virtual нет. Это было ожидаемо. На такой нагрузке работа с потоками занимает относительно малое время по сравнению с бизнес логикой (200 ms в тестах).
Разница между Fixed может быть объяснена тем что плохо подобрано количество потоков в пуле.

Вышла Java 22 - https://habr.com/ru/news/801467/

какие тут проблемы могут быть? (метод get могут вызывать разные потоки одновременно)