Ответ к задаче про сравнение строк:

Первое, что нужно отметить, что тут сравниваются не значения строк, а ссылки на строки. Поэтому ide подчёркивает все равенства и предлагает правильный вариант сравнения значений строк через “equals”

s1 и s2 это один и тот же объект, так как в java есть пул строк, и для s2 не создается новый объект, так как в пуле уже есть строка с таким же значением.
А вот s3 создается через new и в пул строк не попадает. Поэтому s1 и s3 это разные объекты, поэтому сравнение вернёт false
s4 будет гарантированно из пула, так как вызван метод intern.
s5 работает аналогично s2

Выводы:
1) сравнивая объекты через == , можно не всегда получить то, что ожидаешь, поэтому лучше этого не делать и использовать метод equals. Сравнивая через == вы должны знать что делаете.
2) Если ide подчёркивает код, стоит обратить на это внимание, скорее всего у вас проблемы в коде
3) Метод intern перед созданием объекта String смотрит, есть ли этот объект в пуле стрингов и возвращает его. Иначе создается новый объект в пуле.

Статья на эту тему: https://habr.com/ru/post/79913/

Видео, которое рекомендую посмотреть, про intern там тоже идёт речь: https://youtu.be/SZFe3m1DV1A

Какие тут есть проблемы в коде?
#spring

Ответ к последнему вопросу про спринг контроллер (https://t.me/java_interview_tasks/101):
1. Надо сделать поле starterService final. Аннотация @RequiredArgsConstructor добавляет конструктор со всеми final полями, поэтому при создании бина поле starterService не проинициализируется.
2. Не хватает аннотации @PathVariable. Иначе будет всегда collector = null и NPE в collector.toString()

Также был вопрос про @Autowired над полем и над конструктором: https://t.me/java_interview_tasks/62

ArrayList<Integer> имеется ввиду в вопросе

Разъяснение к вопросу про int[] и ArrayList<Integer>:

Пустой массив весит 16 байт , учитывая выравнивание на 8
(про подсчет байтов для конкретного класса был вопрос с более детальным объяснением - https://t.me/java_interview_tasks/56)

[I object internals:
OFF SZ TYPE DESCRIPTION
0 8 (object header: mark)
8 4 (object header: class)
12 4 (array length)
12 4 (alignment/padding gap)
16 0 int [I.<elements>
Instance size: 16 bytes

Массив с 10-ю элементами весит 56 (16 + 10 * 4 (4 - размер int в массиве))
int[]:
[I@2328c243d object externals:
SIZE TYPE VALUE
56. [I [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

Total size: 56


ArrayList из 10-ти элементов выглядит по памяти как показано ниже:
ArrayList<Integer>:
java.util.ArrayList@281e3708d object externals:
SIZE TYPE PATH VALUE
24 java.util.ArrayList (object)
56 [LObject; .elementData [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
16 Integer .elementData[0] 0
16 Integer .elementData[1] 1
16 Integer .elementData[2] 2
16 Integer .elementData[3] 3
16 Integer .elementData[4] 4
16 Integer .elementData[5] 5
16 Integer .elementData[6] 6
16 Integer .elementData[7] 7
16 Integer .elementData[8] 8
16 Integer .elementData[9] 9

Total size: 240

Получается 240 байт против 56 -> разница чуть больше чем в 4 раза между массивом и списком

Разница большая из-за того, что в листе элементы не примитивы, как в массиве, а объекты
Есть библиотеки, которые позволяют хранить примитивы, их довольно много:
например trove4j или fastutil

Для сравнения it.unimi.dsi.fastutil.ints.IntArrayList с 10-ю элементами:

it.unimi.dsi.fastutil.ints.IntArrayList@17695df3d object externals:

ADDRESS SIZE TYPE PATH VALUE
6233247b0 24 IntArrayList (object)
623357278 56 [I .a [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

Total size: 80

Про сравнение производительности можно почитать здесь - https://www.baeldung.com/java-list-primitive-performance

Вопрос к читателям:
Благодаря чему достигается прирост производительности в коллекциях с примитивами, кроме экономии памяти?

Что напечатает код?

Ответ на задачу про instance of:
Если значение, переданное в оператор instance of == null, тогда результат будет false.

Ссылка на спеку: https://docs.oracle.com/javase/specs/jls/se17/html/jls-15.html#jls-15.20.2 (If the value of the RelationalExpression is the null reference (§4.1), then the result is false.)

В jdk 14 появились новые возможности, связанные с instance of.
Главная вещь это то, что теперь не надо делать cast внутри оператора, то есть можно так:
if (obj instanceof String obj) {
System.out.println(obj.toLowerCase());
}
(подробнее тут: https://habr.com/ru/post/477654/)

Известно, что x++ над volitile полем x не атомарен (https://t.me/java_interview_tasks/94), давайте посмотрим насколько серьезными могут быть потери данных в случае гонки:

Вопрос:
Что может напечатать код?

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

#concurrency

Ответ к вопросу про инкремент под гонкой:
Рассуждения аналогичные как и тут:
https://t.me/java_interview_tasks/96
Для примера, посмотрим, как может получится 2 - это самый интересный случай (см. картинку к посту)
Остальные варианты (больше 2) возможно получить аналогичными рассуждениями.

Выводы: этот простой пример показывает, что не синхронизированный счётчик может терять много данных.
Если вам нужно использовать счётчик под гонкой, то надо синхронизировать инкремент или использовать уже синхронизированные счётчики, например, AtomicInteger

Упражнение для читателей:
Доказать, что 0 и 1 напечататься не могут

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

Проблемы в коде:
1) notify нельзя переопределять, потому что он final
2) Если вызывать notify, то нужно это делать внутри synchronized блока
3) lock не инициализируется и будет npe

Что напечатает код?

Объяснение к вопросу про ExecutorService:

ExecutorService проглатывает исключения в случае выполнения Runnable, поэтому если вы отправили на выполнение Runnable, вы обязаны поместить все тело метода внутрь try-catch. Если вы помещаете в ExecutorService Callable, удостоверьтесь, что вы всегда достаете его результат с помощью блокирующего get(), чтобы увидеть исключение если оно будет.

Старая статья про ExecutorService: https://habr.com/ru/post/260953/

Какие проблемы в коде могут быть? Как их можно поправить?

Проблемы , которые могут быть в коде из прошлого поста:
1) код не компилируется: возвращаемый тип должен быть не void, а Integer
2) параметр s может быть null, можно добавить проверку
3) строка s может быть не приводима к int, например, “12we” или ”11111111111111111111111”, в обоих случаях метод выбросит эксепшен, и тут надо выбрать вариант, как обработать такие ситуации:
[0] ничего не делать, возможно, это приемлемое поведение для вашего случая (например: у вас обработка исключений уже продумана в коде, который вызывает данный метод)
[1] проверять входной параметр s в начале метода, перед вызовом parseInt
[2] обернуть вызов parseInt в try-catch
Вариант [1] лучше тем, что в процессе работы не создаётся эксепшен, так как создание эксепшена-тяжелая операция
Вариант [2] может быть лучше, если параметр s почти всегда валидное для int значение, тогда мы экономим на проверке из варианта 1
То есть надо отталкиваться от того, насколько вам важен перформанс в конкретном случае и какие данные приходят на вход в метод.

В следующих постах посмотрим насколько тяжелая операция “throw exception” с точки зрения перформанса и приведу конкретные измерения для разных вариантов

Давайте посмотрим два возможных варианта кода, для обработки невалидных строк из предыдущего поста. Как вы считаете, какой вариант будет быстрее и на сколько для позитивного сценария и для негативного? (Далее будет два опроса)