Ответ к задаче про нахождение среднего:
1 вариант будет сильно отличаться от остальных, так как оперирует с лонгами, и там будут переполнения
2 вариант и 3 отличаются между собой из-за разного порядка суммирования в обычном и параллельном стриме
Главный вопрос в том, почему отличается вариант 2 от варианта 4: doubleStream использует алгоритм, который делает суммирования таким образом, чтобы погрешность была минимальной, а цикл for суммирует в лоб

Ответ на задачу про Map.of():
В доках не указана конкретная реализация, сказано следующее: Returns an unmodifiable map …
В java 17 реализация из класса ImmutableCollections.
Например: ImmutableCollections.EMPTY_MAP, new ImmutableCollections.Map1<>(k1, v1) и тд.
Эти мапы эффективнее.
Если у вас мапа не будет меняться, то лучше использовать эти реализации.

Может ли метод нахождения модуля целого числа из jdk Math.abs() вернуть отрицательный результат?

Ответ на задачу про отрицательный модуль:
Ситуация возможна, если: Math.abs(Integer.MIN_VALUE);
C java 15 добавился метод Math.absExact, он выкидывает exception в этом случае
Реальный кейс, приводящий к проблеме - array[Math.abs(str.hash())], один раз на 4 млрд вы можете получить ArrayIndexOutOfBoundsException
Так же метод из задачи помечен аннотацией @IntrinsicCandidate.
IntrinsicCandidate указывает на то, что данный метод может быть заменён на intrinsic-функцию.
Intrinsic-функция — функция, которую JIT-компилятор может встроить вместо вызова Java-кода с целью оптимизации.
Короче говоря, вместо кода, который внутри метода, в реальности может работать другой код, который будет работать гораздо эффективнее.

Какие пары (x, y) могут напечататься после того, как отработают thread1 и thread2?

Ответ к последнему вопросу:
Проблема тут в том, что происходит инкремент полей под гонкой и операция i++ не атомарна. По факту это две операции: чтение и запись. Может случиться так, что первый поток прочитал значение поля, потом второй поток увеличил значение, а после этого первый поток перетер его, сделав инкремент значения, которое он прочитал в самом начале.
Volatile тут значения не имеет.
Что бы решить проблему, можно использовать AtomicInteger и атомарные операции, например, incrementAndGet()
Следующий вопрос: почему нельзя увидеть x = 0?
Видимость всех переменных гарантируется тем, что перед чтением переменных делается join на тредах, в спеке по этому поводу написано следующее: All actions in a thread happen-before any other thread successfully returns from a join() on that thread.
Прочитать про это можно тут - https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html (17.4.5. Happens-before Order)
Похожая проблема с неатомарностью инкрементов рассмотрена здесь - https://github.com/openjdk/jcstress/blob/master/jcstress-samples/src/main/java/org/openjdk/jcstress/samples/api/API_02_Arbiters.java

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

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

Первое, что нужно отметить, что тут сравниваются не значения строк, а ссылки на строки. Поэтому 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

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

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