Java Interview Tasks
3.9K subscribers
185 photos
1 file
121 links
Реальные вопросы и задачи с собеседований.
Оригинальный авторский контент.
Актуальный материал.
Уровень вопросов от junior до supersenior.

Автор канала - @alexzelentsov

По рекламе: @alexzelentsov и https://telega.in/c/java_interview_tasks
Download Telegram
Java Interview Tasks
Какие проблемы в коде могут быть? Как их можно поправить?
Проблемы , которые могут быть в коде из прошлого поста:
1) код не компилируется: возвращаемый тип должен быть не void, а Integer
2) параметр s может быть null, можно добавить проверку
3) строка s может быть не приводима к int, например, “12we” или ”11111111111111111111111”, в обоих случаях метод выбросит эксепшен, и тут надо выбрать вариант, как обработать такие ситуации:
[0] ничего не делать, возможно, это приемлемое поведение для вашего случая (например: у вас обработка исключений уже продумана в коде, который вызывает данный метод)
[1] проверять входной параметр s в начале метода, перед вызовом parseInt
[2] обернуть вызов parseInt в try-catch
Вариант [1] лучше тем, что в процессе работы не создаётся эксепшен, так как создание эксепшена-тяжелая операция
Вариант [2] может быть лучше, если параметр s почти всегда валидное для int значение, тогда мы экономим на проверке из варианта 1
То есть надо отталкиваться от того, насколько вам важен перформанс в конкретном случае и какие данные приходят на вход в метод.

В следующих постах посмотрим насколько тяжелая операция “throw exception” с точки зрения перформанса и приведу конкретные измерения для разных вариантов
🔥25👍15
Java Interview Tasks
Проблемы , которые могут быть в коде из прошлого поста: 1) код не компилируется: возвращаемый тип должен быть не void, а Integer 2) параметр s может быть null, можно добавить проверку 3) строка s может быть не приводима к int, например, “12we” или ”111111…
Давайте посмотрим два возможных варианта кода, для обработки невалидных строк из предыдущего поста. Как вы считаете, какой вариант будет быстрее и на сколько для позитивного сценария и для негативного? (Далее будет два опроса)
👍6
Как вы считаете, на сколько быстрее parseIf, чем parseCatch в случае невалидной строки (например "1232133141w")?
Anonymous Quiz
48%
примерно в 5 раз
30%
примерно в 50 раз
14%
примерно в 100 раз
9%
больше чем в 500 раз
🤔16🔥10👍1
Как вы считаете, на сколько медленнее parseIf, чем parseCatch в случае валидной строки (например "1232133141")?
Anonymous Quiz
27%
меньше чем на 3%
27%
примерно на 10%
24%
примерно на 50%
22%
примерно на 100%
👍9🔥4🤔3
Java Interview Tasks
Давайте посмотрим два возможных варианта кода, для обработки невалидных строк из предыдущего поста. Как вы считаете, какой вариант будет быстрее и на сколько для позитивного сценария и для негативного? (Далее будет два опроса)
Всем привет.
Экспресс ответ к последнему вопросу про catch/if.

Для негативного варианта (когда приходит невалидная строка) все просто - каждый раз создаётся exception, а это дорогая операция, так как надо создать объект со стек трейсом. Результаты говорят сами за себя.
Результаты позитивного сценария говорят о том, что if хоть и срабатывает каждый раз, но большого оверхеда не вносит.

Выводы: почти всегда лучше вариант с if, кроме случая, когда у вас очень мало запросов с валидными строками (например, меньше 5%)

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

Так же хочу сказать, что мне написало много людей с вопросами, когда будут новые посты, поэтому решил продолжить выкладывать новые вопросы и другой релевантный контент тут, не смотря на большую нехватку времени. Всем спасибо кто дочитал.
👍244🔥4
Свежая конфа по джаве (выложены записи докладов):

Java, Cloud, Data, AI, Robotics, Programming Languages, Security, Architecture, Developer Practices and Culture

https://youtube.com/playlist?list=PLKuh52zVrL6n_LKPLZN_n2tdYjACndZmB
🔥12
Обещал привести пример метода parseCatch для продакшена
Реализация зависит от конкретной логики приложения, которое использует этот метод
Общие вещи:
private Integer parseCatchProd(String s) {
try {
return Integer.parseInt(s);
} catch (NumberFormatException e) {
return null;
}
}
такой вариант не подойдет, потому что мы будем терять exceptions, которые тут будут потеряны
Поэтому можно сделать, например, так:

private Integer parseCatchProd(String s) {
try {
return Integer.parseInt(s);
} catch (NumberFormatException e) {
log.error(e.getMessage(), e);
return null;
}
}

Далее: null возвращать обычно не самая хорошая идея, можно вернуть Optional
или какое-нибудь дефолтное значение, например, -1
Кроме того, возможно вообще не нужно делать catch внутри этого метода, если, например, у вас где-то уровнем выше обрабатываются уже такие ошибки
Как вариант, можно сделать так (если вам не очень критична производительность):

private Optional<Integer> parseCatchProd(String s) {
try {
return Optional.of(Integer.parseInt(s));
} catch (NumberFormatException e) {
log.error(e.getMessage(), e);
return Optional.empty();
}
}

Если это не так придется, как всегда, пожертовать чем-то, например, best practice:)
👍14🔥7👏1
Ещё новость - завтра будет новый вопрос. Готовьтесь
👍15🔥71
Какой из методов будет работать быстрее?
👍13🔥4
Какой из методов будет работать быстрее?
Anonymous Quiz
71%
initInteger1
7%
initInteger2
4%
initInteger3
17%
initInteger4
🔥17👍4
Какой из методов будет работать МЕДЛЕННЕЕ?
Anonymous Quiz
4%
initInteger1
54%
initInteger3
13%
initInteger4
16%
все медленные, это же java
13%
узнать ответы
👍162👎2
На сколько initInteger1 быстрее будет чем initInteger3?
Anonymous Quiz
18%
< на 10% быстрее
29%
на 30%-50% быстрее
32%
в 1,5-2 раза быстрее
21%
> в 10 раз быстрее
👍92
🔥8👍3
👍8🔥42
Java Interview Tasks
Photo
Ответ к вопросу IntVsInteger:
initInteger1 создает примитив, поэтому это самый быстрый вариант.
initInteger2 создает объект-обертку для примитива, бенчмарк показывает, что такой вариант в разы медленнее,
это происходит, потому что initInteger2 создает каждый раз новый объект в хипе + оверхед на создание объекта + GC оверхед
initInteger4 чуть хуже чем создание примитива, так как мы все таки создаем объект изначально, но потом используем кеш
initInteger2 от initInteger3 сильно не отличаются, так как делают примерно одно и тоже

Так же считаю вопросы про конкретные значения между вариантами не корректными. Так как на разных версиях java, разных ОС
и разном hardware результаты могут сильно отличаться. Можно говорить только про результаты на конкретной машине.
Имеет смысл говорить про то, например, что один вариант сильно медленнее или быстрее, понимая из-за чего это происходит.
Поэтому таких вопросов, как последние 3, больше не будет.

Вот такие результаты я получил на своем ноутбуке:

java 8
Benchmark                  Mode  Cnt  Score   Error  Units
IntVsInteger.doNothing avgt 20 0.268 ± 0.006 ns/op
IntVsInteger.initInteger1 avgt 20 2.236 ± 0.018 ns/op
IntVsInteger.initInteger2 avgt 20 3.981 ± 0.104 ns/op
IntVsInteger.initInteger3 avgt 20 4.073 ± 0.145 ns/op
IntVsInteger.initInteger4 avgt 20 2.786 ± 0.043 ns/op


java 17
Benchmark                  Mode  Cnt  Score   Error  Units
IntVsInteger.doNothing avgt 20 0,451 ± 0,017 ns/op
IntVsInteger.initInteger1 avgt 20 2,103 ± 0,068 ns/op
IntVsInteger.initInteger2 avgt 20 4,056 ± 0,168 ns/op
IntVsInteger.initInteger3 avgt 20 4,332 ± 0,195 ns/op
IntVsInteger.initInteger4 avgt 20 2,394 ± 0,058 ns/op
🔥172
Какие значения может напечатать код (thread1 и thread2 запускаются одновременно в разных потоках)?
#jmm #concurrency #java #java_interview_tasks
👍11
Какие значения может напечатать код (thread1 и thread2 запускаются одновременно в разных потоках)?
Anonymous Quiz
40%
-1,42
29%
-1,42,0
19%
42
13%
-1
🔥111
Ответ на вопрос VolatileVsFinal (https://t.me/java_interview_tasks/140) :

Тут речь идет об одном из самых интересных разрешенных сценариев JMM. Это тот факт, что volatile поле не имеет final семантики.
Это означает, что если мы публикуем ссылку объекта под гонкой, то мы можем увидеть дефолтное значение для volatile поля
Поэтому в данном случае 0 вполне можно получить.

Этот эффект можно увидеть на некоторых платформах, например AArch64:
RESULT SAMPLES FREQ
-1 1,428,517,070 91.74%
0 7,105 <0.01%
42 128,534,641 8.25%
👍16🔥7🤯31