Java Interview Tasks

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

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

Обещал привести пример метода 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 parseCatchProd(String s) { try { return Optional.of(Integer.parseInt(s)); } catch (NumberFormatException e) { log.error(e.getMessage(), e); return Optional.empty(); } } Если это не так придется, как всегда, пожертовать чем-то, например, best practice:)

Свежая конфа по джаве: Java, Cloud, Data, AI, Robotics, Programming Languages, Security, Architecture, Developer Practices and Culture https://youtube.com/playlist?list=PLKuh52zVrL6n_LKPLZN_n2tdYjACndZmB

Всем привет. Экспресс ответ к последнему вопросу про catch/if. Для негативного варианта (когда приходит невалидная строка) все просто - каждый раз создаётся exception, а это дорогая операция, так как надо создать объект со стек трейсом. Результаты говорят сами за себя. Результаты позитивного сценария говорят о том, что if хоть и срабатывает каждый раз, но большого оверхеда не вносит. Выводы: почти всегда лучше вариант с if, кроме случая, когда у вас очень мало запросов с валидными строками (например, меньше 5%) Код, который использовался в вопросе не стоит рассматривать как идеальный-супер-продакшен код, он сделан таким, что бы убрать ненужные для измерений действия, которые могут вносить оверхед в результаты. Так же хочу сказать, что мне написало много людей с вопросами, когда будут новые посты, поэтому решил продолжить выкладывать новые вопросы и другой релевантный контент тут, не смотря на большую нехватку времени. Всем спасибо кто дочитал.

Тинькофф приглашает на One Day Offer Ищем Java- и Kotlin-разработчиков с опытом от трех лет, чтобы сделать им оффер за день. В течение дня вы общаетесь с командой, а после получаете оффер, если вам понравится команда, работа подойдет по условиям, а задачи — по скиллам. Встречаемся 28 мая онлайн. Успейте подать заявку до 26 мая. В течение трех дней вернемся с обратной связью: https://l.tinkoff.ru/one_day_offer_java_

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

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

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

Объяснение к вопросу про ExecutorService: ExecutorService проглатывает исключения в случае выполнения Runnable, поэтому если вы отправили на выполнение Runnable, вы обязаны поместить все тело метода внутрь try-catch. Если вы помещаете в ExecutorService Callable, удостоверьтесь, что вы всегда достаете его результат с помощью блокирующего get(), чтобы увидеть исключение если оно будет. Старая статья про ExecutorService: https://habr.com/ru/post/260953/

Что напечатает код?

Проблемы в коде: 1) notify нельзя переопределять, потому что он final 2) Если вызывать notify, то нужно это делать внутри synchronized блока 3) lock не инициализируется и будет npe

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

Все о Java в одном месте! DMdev - это настоящая дорожная карта джависта на YouTube. Новичок, junior, middle, senior - каждый найдёт информацию для себя. Попав в комьюнити DMdev, многие жалеют лишь об одном - что не попали сюда раньше. Не повторяй ошибок других - переходи на канал и становись лучшим в Java программировании🙌🏻

Ответ к вопросу про инкремент под гонкой: Рассуждения аналогичные как и тут: https://t.me/java_interview_tasks/96 Для примера, посмотрим, как может получится 2 - это самый интересный случай (см. картинку к посту) Остальные варианты (больше 2) возможно получить аналогичными рассуждениями. Выводы: этот простой пример показывает, что не синхронизированный счётчик может терять много данных. Если вам нужно использовать счётчик под гонкой, то надо синхронизировать инкремент или использовать уже синхронизированные счётчики, например, AtomicInteger Упражнение для читателей: Доказать, что 0 и 1 напечататься не могут

Известно, что x++ над volitile полем x не атомарен (https://t.me/java_interview_tasks/94), давайте посмотрим насколько серьезными могут быть потери данных в случае гонки: Вопрос: Что может напечатать код? (Варианты ответов в следующем опросе, в каждом варианте перечислены списки значений которые могут быть выведены на экран) #concurrency