Хорошее видео про то , как надо писать commit messages
https://www.youtube.com/watch?v=uBhpBOX8VYg

#не_реклама

Ответ к вопросу new Integer(300) или Integer.valueOf(300):

valueOf в общем случае использовать предпочтительнее
Вариант new Integer(...) с 9-ой версии java помечен как @Deprecated(since="9", forRemoval = true) и будет удален в будущих версиях, то есть вам будет сложнее мигрировать на новые версии java с таким кодом.

Код valueOf:
@IntrinsicCandidate
public static Integer valueOf(int i) {
if (i >= IntegerCache.low && i <= IntegerCache.high)
return IntegerCache.cache[i + (-IntegerCache.low)];
return new Integer(i);
}
Используется IntegerCache.cache, что может дать прирост производительности
Так же обратите внимание на аннотацию @IntrinsicCandidate, интринсик даст прирост производительности
Про интринсики можно почитать подробнее тут - https://www.baeldung.com/jvm-intrinsics
или тут - https://habr.com/ru/post/352086/

Ответ на вопрос про currentTimeMillis и toEpochMilli:

Тут очевидно, что гораздо быстрее (1) так как:
1) @IntrinsicCandidate public static native long currentTimeMillis(); - IntrinsicCandidate
(Про интринсики я писал в прошлом посте - https://t.me/java_interview_tasks/167)
2) (2) создает объект Instant.now() и далее вызывается метод .toEpochMilli(), который выполянет конвертацию -> больше операций + оверхед по памяти

Результаты у меня получились такие:
VM version: JDK 17.0.1, OpenJDK 64-Bit Server VM, 17.0.1+12-39

Units: ops/s
Benchmark            Score            Error        
currentTimeMillis  205488100,839 ± 5397269,355
toEpochMilli       65060918,825 ± 3064529,122

Код бенчмарка ниже:

@BenchmarkMode(Mode.Throughput)
@Fork(1)
@State(Scope.Thread)
@Warmup(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS)
public class SystemCalls {

@Benchmark
public long curr() {
return System.currentTimeMillis();
}

@Benchmark
public long instant() {
return Instant.now().toEpochMilli();
}
}

Старый видос, но актуальный

https://youtu.be/Vlb_Is-rRTQ

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

Ответ:
тут нарушен порядок HB сначала идет запись в volatile поле g а потом в x, поэтому чтение из g еденицы не дает гарантий относительно x.
Поэтому возможны все варианты: "0, 0", "1, 1", "0, 1", "1, 0"

Пример использования конструкции с правильным HB тут - https://t.me/java_interview_tasks/53

Что будет напечатано?

Задача с собеседования:
Sort a large input stream of 3-byte unsigned integers (e.g. 16GB total size) not using disk provided you run 32-bit Java

Ваши варианты пишите в комментарии

Правильный вариант: может быть и true и false

Дело в том, что вызов thenRun у того же future, но во втором потоке, может привести к срабатыванию callback в первом thenRun.
При этом callback первого thenRun будет вызван во втором потоке.

Это происходит в тот момент, когда future.complete(null) начало выполняться, но ещё не успело вызвать callbacks,
а во втором потоке вызвался thenRun, который и выполнит все остальные callbacks на этом future но уже в своём потоке.

Проблем решается просто:

//основной поток
Thread mainThread = Thread.currentThread();

//создаём второй поток
Executor executor = Executors.newSingleThreadExecutor();

CompletableFuture<Void> future = new CompletableFuture<>();
CompletableFuture<Void> secondThreadFuture = future.thenRun(() -> {
System.out.println(Thread.currentThread() == mainThread);
});

//просто добавляем callback к тому же future в другом потоке
executor.execute(() -> {
secondThreadFuture.thenRun(() -> {
//nop
});
});

//завершаем future
future.complete(null);

Мы просто добавили secondThreadFuture, которая зависит от результата исходной future.
И вызов на ней thenRun во втором потоке не приводит к возможному срабатыванию callbacks на исходной future.

Для гарантированного вызова callbacks в заданных пользователем потоках у CompletableFuture существуют async реализации методов,
например — thenRunAsync, которым нужно передавать Executor. Но async-версии методов могут работать медленней, чем обычные.

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

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

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

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

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

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