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

public static List<?> add(Long l1, Long l2, Long l3) {
return List.of(l1, l2, l3);
}

Оцените код по 10-бальной шкале

Тут главная проблема в том, что первоначальный эксепшен теряется и непонятно будет какая ошибка случилась. Здесь нужно либо прокинуть этот эксепшен дальше либо залоггировать его.

Нет, конструктор не может быть synchronized, это запрещено спецификацией, аргументация примерено такая - JVM гарантирует, что только один поток может вызвать конструктор в данный момент времени.
Вот почему нет необходимости объявлять конструктор как synchronized, и это недопустимо в Java.

PS. У меня этот вопрос спрашивали на собесах несколько раз. Интересовались не только ответом может или не может, но и причинами, почему так сделали.

Что напечатает код?
double a = Math.pow(10, 100);
double b = Math.pow(10, -100);
double c = a + b;
System.out.println(c);

Про то, как надо дебажить , используя idea:

https://www.youtube.com/watch?v=U0lGmE8DW9U

Здесь проблема в том, что сумма будет ровна 1,0..01е199 , где в мантиссе числа 199 нулей и поэтому это число нельзя представить точно в виде double (там на мантиссу выделяется 53 бита), поэтому будет округление

Еще вопросы про double:
https://t.me/java_interview_tasks/85
https://t.me/java_interview_tasks/150

Какие значения может напечатать код (thread1 и thread2 запускаются одновременно в разных потоках)?

Ответ к задаче про atomic (https://t.me/java_interview_tasks/195):
Проблема в том, что внутри класса AtomicInteger поле value не final, а volatile поле не имеет final семантики, поэтому если мы публикуем ссылку объекта пол гонкой, то можно увидеть дефолтное значение поля (0 в данном случае)
Похожая задача была тут - https://t.me/java_interview_tasks/140

0 можно получить на AArch64:
RESULT SAMPLES FREQ
-1 1,358,737,999 90.09%
0 8,322 <0.01%
42 149,426,735 9.91%


Вопрос для читателей: как данную проблему можно обойти?

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

Проблема тут в том, что параллельный стрим запускается в commonThreadPool , этот тред пул один - он предназначен для неблокирующих операций, а в данном примере кода в нем будут запускаться сетевые запросы.
Это может привести к тому, что пока данный стрим будет работать и блокироваться на сетевых вызовах, остальные параллельные стримы и CompletableFuture's в системе будут висеть в очереди.
Статьи на эту тему:
https://dzone.com/articles/be-aware-of-forkjoinpoolcommonpool
https://www.baeldung.com/java-8-parallel-streams-custom-threadpool

Ответ: "test"
Способ вычисления хэша map, set, list - это часть контракта соответствующих интерфейсов. Каждая реализация должна использовать формулу, указанную в контракте. Поэтому поведение будет общим для всех JDK.
Посмотрим теперь, какой же контракт и конкретные формулы для подсчета хеша у мапы.

"The hash code of a map is defined to be the sum of the hash codes of each entry in the map's entrySet() view."

Посмотрим, как вычисляется хешкод у Map.Entry:
"The hash code of a map entry e is defined to be:
(e.getKey()==null ? 0 : e.getKey().hashCode()) ^
(e.getValue()==null ? 0 : e.getValue().hashCode())"

Зная это, мы можем посчитать хешкод нашей мапы: он будет равен 0. Почему? Так как у единственной Map.Entry совпадают значения ключа и значения, то их хешкоды будут совпадать, а значит хешкод Map.Entry будет равен 0 (XOR двух одинаковых чисел дает всегда 0).
После добавления второго Map.Entry хешкод останется равным 0, так как там тоже совпадают значения ключа и значения. Повезло, повезло.
В итоге при вызове метод get будет искать Map.Entry в нужном бакете и, встретив нужную ноду, вызовет equals, который вернет true, так как при вставке значение ключа не копируется, и он будет отображать все изменения, которые с ним происходили.

Естественно, изменять ключ после вставки в HashMap крайне не рекомендуется, иначе потом можно его не найти. Но в данном конкретном случае нам повезло, что хешкод не изменился.

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