Java Interview Tasks

Немного не по теме канала, но что бы все были в курсе: На прошлой неделе была выявлена уязвимость в суперпопулярной библиотеке log4j, если даже вы ее явно не используете, то скорее всего она у вас где-нибудь внутри спринга, эластика и тп Подробности тут: https://isc.sans.edu/diary/rss/28120

Есть arrayList из 100 объектов, нужно преобразовать его в массив. Какой вариант будет самым быстрым? (JDK 11 64-Bit Server VM, 11-LTS, VM options: "-XX:+UseParallelGC", "-Xms1g", "-Xmx1g" ) Дополнительные вопросы: если элементов в коллекции не 100, а 10, 1000, 1, 0 , какой из вариантов будет быстрее? Объяснения или рассуждения пишите в комментариях. #microbenchmarking

Ответ на задачу про аннотацию @Autowired: https://t.me/java_interview_tasks/62 @Autowired над полем и над сеттером плох тем, что вы можете инициализировать объект с null полями (например в тестах) @Autowired над конструктором решает эту проблему и рекомендован к использованию. Один из вариантов использования @Autowired над сеттером это проблема с циклическими зависимостями, но надо понимать, что это не решение проблемы, а просто workaround В случае если вы используете @Autowired над конструктором, вы получите ошибку при старте контекста и сможете сразу исправить циклические зависимости в бинах Почитать про это можно тут: https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#beans-dependency-resolution

Ответ на вчерашнюю задачу: Stream в java lazy и поэтому начинает выполнение в момент, когда вызвана терминальная операция, поэтому CME не будет. Ещё одна похожая задача тут: https://t.me/java_interview_tasks/11

Какой будет результат выполнения кода? public static void main(String[] args) { List<Integer> integers = new ArrayList<>(); integers.add(1); integers.add(2); integers.add(3); final Stream<Integer> stream = integers.stream(); integers.add(4); stream.forEach(System.out::println); }

Размер экземпляра объекта А Размер считается так в 64 битной jvm: 12-байтовый заголовок (object header: mark, object header: class), дополненный до размера, кратного 8-ми байтам Далее идут поля, уложенные максимально компактно, учитывая выравнивание на 8 И в данном случае еще будет 6 байтов - дырка после выравнивания на 8 (object alignment gap) То есть, напрмер, можно было бесплатно добавить еще один char и int в объект, размер бы не изменился Подробнее: OFF SZ TYPE DESCRIPTION VALUE 0 8 (object header: mark) N/A 8 4 (object header: class) N/A 12 4 int A.i1 N/A 16 8 long A.l1 N/A 24 2 char A.ch1 N/A 26 6 (object alignment gap) Instance size: 32 bytes Space losses: 0 bytes internal + 6 bytes external = 6 bytes total

Какой размер будет у экземпляра объекта А? public class A { char ch1; long l1; int i1; } # openjdk-17.0.1 # Running 64-bit HotSpot VM. # Using compressed oop with 3-bit shift. # Using compressed klass with 3-bit shift. # Objects are 8bytes aligned. Обоснование пишите в комментариях

Ответ на вчерашнюю задачу: запрещённый вариант y=1,x=0, так как y - volatile и мы увидели уже в нем 1 , то все что до этого было записано в потоке thread1, мы увидим тоже (больше подробностей и примеров есть тут - https://github.com/openjdk/jcstress/blob/master/jcstress-samples/src/main/java/org/openjdk/jcstress/samples/jmm/basic/BasicJMM_06_Causality.java)

Какие варианты вывода могут быть? (y,x) (похожая задача была тут - https://t.me/java_interview_tasks/26) (Методы thread1 и thread2 запускаются в разных потоках, одновременно, один раз каждый) public class Test { int x; volatile int y; public void thread1() { x = 1; y = 1; } public void thread2() { System.out.println(y); System.out.println(x); } }

Ответ к последнему вопросу: Удаление элемента приведет к сдвигу в массиве и добавлению null в последнем элементе: ["1", "2", "3"] -> ["1", "3", null] и дальше вылетит NPE, так как сравнение сделано неверно (см предыдущую задачу про сравнения строк - https://t.me/java_interview_tasks/46) Еще один вопрос почему раньше не вылетает CME: stream().forEach() это по факту spliterator().forEachRemainig(), а он делает проверку на concurrent modification один раз в конце для оптимизации, поэтому ConcurrentModificationException не вылетает в данном примере

Какой будет результат выполнения кода?

Ответ на вчерашнюю задачу: Сравнение происходит не значений, а ссылок объектов. Но в java есть пул для объектов типа Long (от -127 до 127 включительно) поэтому первое равенство выполняется так как сравнивается один и тот же объект, а второе = false, так как сравниваются разные объекты. Идея именно поэтому и показывает warning, предлагая сравнивать через equals