Ответ к последнему вопросу:
Объявление массива как volatile не делает доступ к его элемента volatile.
Поэтому hb семантика тут не применима и никаких гарантий относительно исполнения дать нельзя
Правильный вариант - "0, 0", "1, 1", "0, 1", "1, 0"
Были вопросы откуда может взяться вариант "1, 0":
Тут происходит запись элементов в массив и их чтение под гонкой,
jmm не дает в этом случае каких то гарантий на порядок выполнения операций.
Например компилятор может выполнить запись в другом порядке,
отличающимся от порядка в коде, то есть сначала записать a[1] = 1 а потом a[0] = 1

Вот пример, когда volatile даёт гарантии видимости в другом треде: https://t.me/java_interview_tasks/53

Вопрос для читателей: что нужно сделать, что бы вариант (1,0) был запрещён?

Разъяснение:
В конструктор BigDecimal(4.4) передаётся примитив double, в котором вместо 4.4 лежит
4.4000000000000003552713678800500929355621337890625
Поэтому объект BigDecimal будет хранить это число, а не 4.4

Вопрос к читателям: как переписать код, что бы результат стал точным (8.8) ?

Новая рубрика - говнокод.

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

Проблемы:
1) код вообще не компилируется, так как метод void, но есть return
2) relatedId странное название, по факту это carId
3) внутри map, завернут еще один optional, это не нужно делать - тут лучше использовать flatMap, он уже возвращает optional
4) 'c' внутри map запутывает, это car, но такое название уже занято и, видимо, поэтому назвали 'c', лучше назвать как то более понятно, например, car, а параметр метода carToFill
5) 'c' внутри ifPresent запутывает еще больше, это owner и надо назвать именно так
6) если поправить пунтк 3, то и вложенный ifPresent внутри ifPresent'a будет не нужен
7) Возможно лучше вообще сделать так, что бы метод возвращал matadata, а потом уже другой метод проставлял в Car метадату
8) optional.of вернёт npe для null, правильно использовать optional.ofNullable

Если нашли что-то ещё - пишите в комменты

Код может быть например такой

Какой из классов immutable?

Ответ к вопросу про immutability:

Immutable класс — это класс, который после инициализации не может изменить свое состояние. То есть если в коде есть ссылка на экземпляр иммутабельного класса, то любые изменения в нем приводят к созданию нового экземпляра.

Чтобы класс был immutable, он должен соответствовать следующим требованиям:
1) Все поля класса должны быть приватными в соответствии с принципами инкапсуляции.
2) Для корректного создания экземпляра в нем должны быть параметризованные конструкторы, через которые осуществляется первоначальная инициализация полей класса.
3) Для исключения возможности изменения состояния после инстанцирования, в классе не должно быть сеттеров.
4) Должен быть объявлен как final, чтобы от него нельзя было наследоваться. Иначе дочерние классы могут нарушить иммутабельность.
5) Для полей-коллекций и ссылочных полей необходимо делать копии, чтобы гарантировать их неизменность.

Class3 immutable?

Class3 не immutable, так как в конструкторе присваивается массив, ссылка на который осталась вне этого класса. Его можно изменять там, откуда он пришел и эти изменения будут менять поле array внутри Class3
Пример immutable класса, в котором эта проблема решена:

Хорошее видео про то , как надо писать 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