Собеседование Java Middle | Реальное собеседование | Jetbulb

Получи реальный опыт решения коммерческих задач в Agile команде

Выпуск серии "Техническое собеседование" на позицию Java Middle Developer.
Вопросы и ответы по темам: разработка и тестирование приложений, многопоточность, Java Framework Collection, Spring Framework, Базы Данных и транзакции в БД.

Программа:
00:00 - Введение
01:28 - Требования к кандидату
03:09 - Цикл разработки
06:39 - Тестирование приложений
09:41 - Коллекции или Java Collection Framework
22:25 - Многопоточность
31:18 - Spring Framework и Базы Данных
48:02 - Выводы

Мы в социальных сетях:

Запись на обучение и собеседование:

[vladimirblagin]

45:28 Послушал про оптимистичную и пессимистичную блокировку. Улыбнуло. Объясню вам на пальцах, чтобы вы других не вводили в заблуждение. Смотрите. Прежде всего блокировка нам нужна только когда мы что-то меняем. И блокировка нужна, чтобы измененные данные сохранили свою целостность. Не были утрачены в какой-то части в результате наложившихся параллельных изменений. Никакая блокировка не должна запрещать другим читать данные (если не мегаспециальные сценарии). Это касается только функционала изменения данных. Например, открыли на редактирование какой-то документ. Поредактировали и сохранили.

Что такое оптимистическая блокировка и почему она так называется. Оптимистическая блокировка берет данные в работу на изменение и никому не запрещает взять эти же данные на изменения параллельно. Это такие оптимисты, которые надеются успеть изменить документ и сохранить его пока никто не успел взять этот документ на изменение. Далее, кто первый встал того и тапки, кто первый записался в базу данных, тот молодец, а второй "неудачный оптимист" получит отлуп по блокировке, если механизм блокировки вообще есть. Один из вариантов реализации оптимистичной блокировки является версионирование данных. Каждый entity имеет в БД поле с номером версии, он меняется в БД когда кто-то изменил этот блок данных entity. Соответственно при попытке записаться сравнивается версия исходная с которыми данные получены и версия на момент записи. И если они отличаются, то отказ. За это отвечает та самая аннотация @Version. Это работает как видите и на уровне приложения, и на уровне БД.

Теперь, пессимистичная блокировка. Тут работают пессимисты, они не действую по принципу "авось никто не успеет поменять документ, пока я тут его же меняю", они берут данные в работу на изменение и запрещают другим брать эти же данные на изменение, читать - пожалуйста. Но брать на изменение второму не дадут, жди пока первый разблокирует данные. Это гарантирует первому спокойное сохранение какого-то очень важного документа, важного начальника, который не будет повторять дважды и бегать за уведенными тапками. Для такого типа блокировки где-то, в БД или в приложении выставляется признак, что данные взяты на изменение, кем, когда. И все остальные (жаждущие изменить, читать - пожалуйста ) ждут, механизм может поддерживать автоматическую разблокировку через таймаут. Если кто-то взял документ на изменение и ушел в декретный отпуск, а другим его нужно изменять.

Оптимистичная блокировка хороша, когда данные не критичны, можно повторить изменения. Получил отлуп, перечитал данные и внес в новую версию уже свое, если вообще потребуется, а то может коллега уже все прописал. И обычно используется когда нет высокой конкуренции. Главное, она не блокирует работу с документом на изменение, она блокирует прием результата изменений, если кто-то успел документ изменить. Плюс: бери документ на изменение кто хочет, кто первый успел, тот молодец. Минусы: при блокировке приходится перечитывать новую измененную версию и повторять всю работу по изменению снова.
Пессимистичная блокировка нужна когда данные оперативно меняются в условиях высокой конкуренции или когда важный документ, который переделывать повторно трудозатратно. Плюс: все что вы изменили гарантированно примется. Минусы: остальные документ изменить не могут пока вы его "держите" на изменение.
Возможны гибридные варианты стратегии блокировки. Например, какие-то типы документов работают в оптимистической стратегии, какие-то особо важные в пессимистической. Или даже так: первые N часов/минут документ работает в режиме пессимистической блокировки, потом переключается в режим оптимистической. Тогда достигается комбинация положительных сторон двух стратегий и определенный компромисс недостатков (но это уже не про Spring)

[physicsofthewonderful]

Спасибо огромное за Ваш труд и время потраченные на создание канала. Полезная информация для подготовки к собеседовании, приятная подача.
Особенно радует текст в начале видео!

[Грант]

Спасибо огромное за столь большой объем качественной информации!

[Mdfnik]

спасибо за старания, все супер, смотрится на одном дыхании, все понятно и интересно объясняется. Полезное и приятное время препровождение )

[A_Rakh]

Спасибо за данный ролик. Много что узнал нового для себя. Как раз готовлюсь к собесам :)

[FilippTurbanov]

Громадное спасибо за подобный контент! Во-первых, это невероятно интересная информация, во-вторых - необычайно полезная для всех!
Автору канала успехов!

[kkrxjdzs]

Контент топчик! Максон спасибо :) Очень много интересного!

[AnastasiaKolevatykh]

Спасибо за качественные и полезные выпуски 😊

[alekseizhitenev]

спасибо за такого рода видео, очень много новых нюансов узнаю)

[artemlisitsyn]

Очень познавательно, Макс, спасибо! Много нового для себя подчерпнул особенно про аннотацию transactional, но просмотрев, понял, что много вещей будучи джуном уже знаю, чем был приятно удивлен, еще раз спасибо, продолжай в том же духе, хотелось бы еще хотя бы 1 пример интервью (или такого же формата как это видео) вопросов мидлу.

[eskelgarsio]

Сейчас такое у джунов спрашивают) спасибо за видео, хорошо объяснил ответы на вопросы

[artemvoloshyn]

Дякую, за цікавий та корисний контент 🙂

[go-with-go]

Очень круто! Спасибо за разбор интервью - это действительно полезно

[maks]

Даже для джуна это интересно. Круто. Спасибо за информацию)

[rkoinfr]

По больше бы таких видео))
Именно про миддлов особенно лайв кодинг))

[АлександрНиколаевич-сж]

Просмотрел, сделал конспект ))) Спасибо!

[kirill]

Меня на джуна сильнее спрашивали, это было 2 года назад :)

[alevadnaya]

Про базы и транзакции - класс, интересно

[milordplus]

Спасибо за видео! Немного дополню про мапу, порог называется loadFactor, и он напрямую зависит от initialCapacity.
Как было сказано - капасити по умолчанию 16, а лоадфактор 0, 75. Это означает, что с 12го элемента мапа будет увеличена вдвое и так в прогрессии.

[katefedorova]

Спасибо, про уровни изоляции транзакций было полезно