Едем дальше

Едем дальше.

Ну, в общем, в оговоренное время подключаюсь в конфу с интервьюером. Собеседовал меня рандомный тимлид одной из продуктовых команд Б-Банка. Сам по себе чувак приятный и веселый. Собес шёл чуть больше часа и в целом был довольно насыщенным и интересным.

Начало ознаменовалось коротким код-ревью, которых в течение этой секции было несколько. Сам код для ревью ничего сверхъестественного из себя не представлял: хранение и манипуляции с деньгами в double, синтаксические ошибки, незакрытые ресурсы, нарушение слоёв (сервисного и DAO), пустой catch, и тому подобное.

Второе ревью было на тему многопоточности: был некий код, который пытался быть многопоточным счётчиком. Нужно было оценить его работоспособность и починить. Тут же обсуждали различные артефакты многопоточности — прошлись по всему, от низкого уровня (volatile, synchronized, мониторы и т. д.) до всяческих абстракций (Thread, Atomic-классы и CAS-операции, CountDownLatch, ReentrantLock, ThreadLocal, тредпулы).

Также был вопрос, на котором я, к своему стыду, затупил: чем отличается ConcurrentHashMap от SynchronizedMap? Отличается оно (для тех, кто не знает) гранулярностью блокировки: ConcurrentHashMap использует блокировки на уровне Entry, а SynchronizedMap блокируется на объект мапы целиком. Ну а что ответил тогда я? Даже говорить не хочу :D

И в целом на этом многопоточка подошла к концу.

Как ранее писал, были вопросы и про JIT-компиляцию — говорили о tiered compilation, обсуждали отличия уровней компиляции и в какие оптимизации умеет JIT. Очень интересная статья на эту тему:

🔹 Часть 1

🔹 Часть 2

Рекомендую, даже если не планируете собеседоваться в Б-Банк.

Также бегло обсуждали сборку мусора — здесь без фанатизма, достаточно было общего концептуального ответа.

Spring затронули совсем мельком: был вопрос про автоконфигурации и стартеры, нужно было рассказать, как это работает.

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

Первый кейс: багофикс

Ситуация из одного из ревью:

java

@Transactional

public void someMethod(Data data) {

DataEntity dataEntity = mapper.toDataEntity(data);

DataEntity savedDataEntity = someRepository.save(dataEntity);

kafkaBroker.sendMessage("SOME.TOPIC", savedDataEntity.getId());

}

Метод сохраняет данные в БД и отправляет в Kafka сообщение, которое должно инициировать их обработку. На первый взгляд всё ок, но если после коммита транзакции в Kafka у нас моргнёт сеть к БД, то транзакция может не закоммититься, и мы получим неконсистентное состояние: сообщение есть, а данных для обработки — нет.

Решений тут несколько, но если хочешь блеснуть чешуёй, нужно сказать два заветных слова: OUTBOX PATTERN. Погуглите, очень рекомендую знать — в 2/3 компаний у меня про него спрашивали. Ловкий фокус, де-факто стандарт, если нужна надёжность в таких сценариях.

Второй кейс: утечка памяти

Есть приложение с кэшем в памяти. Оно начинает падать по OutOfMemoryError. Как быстро потушить пожар, не вникая глубоко в логику кэширования?

Тут получился забавный момент: я начал рассказывать про WeakReference и SoftReference, что, наверное, где-то есть Map, и можно попробовать заменить одно на другое. Но интервьюер, преисполненный моим ответом, ждал от меня простого житейского: «Давайте добавим памяти» 😄

Далее была SQL-задача (о которой писал выше). Все три задачи из платной секции тренажёра для Б-Банка отличаются от задачи на собеседовании только названиями сущностей. Решите их — решите задачу на собесе на 100500%.

После SQL были вопросы про масштабирование: шардирование, партиционирование. Вскользь обсудили EXPLAIN ANALYZE. Ну и на этом, собственно, всё. Через некоторое время вернулся HR с новостью, что секция пройдена, и была запланирована менеджерская секция. О ней дальше 👇