Объяснение к вопросу про ExecutorService:

ExecutorService проглатывает исключения в случае выполнения Runnable, поэтому если вы отправили на выполнение Runnable, вы обязаны поместить все тело метода внутрь try-catch. Если вы помещаете в ExecutorService Callable, удостоверьтесь, что вы всегда достаете его результат с помощью блокирующего get(), чтобы увидеть исключение если оно будет.

Старая статья про ExecutorService: https://habr.com/ru/post/260953/

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

Проблемы , которые могут быть в коде из прошлого поста:
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” с точки зрения перформанса и приведу конкретные измерения для разных вариантов

Давайте посмотрим два возможных варианта кода, для обработки невалидных строк из предыдущего поста. Как вы считаете, какой вариант будет быстрее и на сколько для позитивного сценария и для негативного? (Далее будет два опроса)

Всем привет.
Экспресс ответ к последнему вопросу про catch/if.

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

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

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

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

Свежая конфа по джаве (выложены записи докладов):

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

https://youtube.com/playlist?list=PLKuh52zVrL6n_LKPLZN_n2tdYjACndZmB

Обещал привести пример метода 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:)

Ещё новость - завтра будет новый вопрос. Готовьтесь

Какой из методов будет работать быстрее?

Свежий видос про собеседования:
#нереклама

https://youtu.be/9Y32VbdsAkA

Ответ к вопросу 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

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