45:28 Послушал про оптимистичную и пессимистичную блокировку. Улыбнуло. Объясню вам на пальцах, чтобы вы других не вводили в заблуждение. Смотрите. Прежде всего блокировка нам нужна только когда мы что-то меняем. И блокировка нужна, чтобы измененные данные сохранили свою целостность. Не были утрачены в какой-то части в результате наложившихся параллельных изменений. Никакая блокировка не должна запрещать другим читать данные (если не мегаспециальные сценарии). Это касается только функционала изменения данных. Например, открыли на редактирование какой-то документ. Поредактировали и сохранили. Что такое оптимистическая блокировка и почему она так называется. Оптимистическая блокировка берет данные в работу на изменение и никому не запрещает взять эти же данные на изменения параллельно. Это такие оптимисты, которые надеются успеть изменить документ и сохранить его пока никто не успел взять этот документ на изменение. Далее, кто первый встал того и тапки, кто первый записался в базу данных, тот молодец, а второй "неудачный оптимист" получит отлуп по блокировке, если механизм блокировки вообще есть. Один из вариантов реализации оптимистичной блокировки является версионирование данных. Каждый entity имеет в БД поле с номером версии, он меняется в БД когда кто-то изменил этот блок данных entity. Соответственно при попытке записаться сравнивается версия исходная с которыми данные получены и версия на момент записи. И если они отличаются, то отказ. За это отвечает та самая аннотация @Version. Это работает как видите и на уровне приложения, и на уровне БД. Теперь, пессимистичная блокировка. Тут работают пессимисты, они не действую по принципу "авось никто не успеет поменять документ, пока я тут его же меняю", они берут данные в работу на изменение и запрещают другим брать эти же данные на изменение, читать - пожалуйста. Но брать на изменение второму не дадут, жди пока первый разблокирует данные. Это гарантирует первому спокойное сохранение какого-то очень важного документа, важного начальника, который не будет повторять дважды и бегать за уведенными тапками. Для такого типа блокировки где-то, в БД или в приложении выставляется признак, что данные взяты на изменение, кем, когда. И все остальные (жаждущие изменить, читать - пожалуйста ) ждут, механизм может поддерживать автоматическую разблокировку через таймаут. Если кто-то взял документ на изменение и ушел в декретный отпуск, а другим его нужно изменять. Оптимистичная блокировка хороша, когда данные не критичны, можно повторить изменения. Получил отлуп, перечитал данные и внес в новую версию уже свое, если вообще потребуется, а то может коллега уже все прописал. И обычно используется когда нет высокой конкуренции. Главное, она не блокирует работу с документом на изменение, она блокирует прием результата изменений, если кто-то успел документ изменить. Плюс: бери документ на изменение кто хочет, кто первый успел, тот молодец. Минусы: при блокировке приходится перечитывать новую измененную версию и повторять всю работу по изменению снова. Пессимистичная блокировка нужна когда данные оперативно меняются в условиях высокой конкуренции или когда важный документ, который переделывать повторно трудозатратно. Плюс: все что вы изменили гарантированно примется. Минусы: остальные документ изменить не могут пока вы его "держите" на изменение. Возможны гибридные варианты стратегии блокировки. Например, какие-то типы документов работают в оптимистической стратегии, какие-то особо важные в пессимистической. Или даже так: первые N часов/минут документ работает в режиме пессимистической блокировки, потом переключается в режим оптимистической. Тогда достигается комбинация положительных сторон двух стратегий и определенный компромисс недостатков (но это уже не про Spring)
Для чего тогда вообще нужна оптимистическая блокировка, если она точно так же не позволяет одному что-то менять, если меняет и другой? Зачем тогда вообще давать доступ, что-то делать, если будет откатываться всё равно?
@@user-iy1zv9ej1d Применение оптимистичного параллелизма способствует повышению производительности благодаря тому, что не требуется блокировка записей, которая требует дополнительных ресурсов сервера. Кроме того, для блокировки записей требуется постоянное соединение с сервером базы данных. При использовании модели оптимистичного параллелизма такая необходимость отсутствует, поэтому соединения с сервером можно применять для обслуживания большего количества клиентов за меньшее время.
Спасибо огромное за Ваш труд и время потраченные на создание канала. Полезная информация для подготовки к собеседовании, приятная подача. Особенно радует текст в начале видео!
Очень познавательно, Макс, спасибо! Много нового для себя подчерпнул особенно про аннотацию transactional, но просмотрев, понял, что много вещей будучи джуном уже знаю, чем был приятно удивлен, еще раз спасибо, продолжай в том же духе, хотелось бы еще хотя бы 1 пример интервью (или такого же формата как это видео) вопросов мидлу.
Громадное спасибо за подобный контент! Во-первых, это невероятно интересная информация, во-вторых - необычайно полезная для всех! Автору канала успехов!
Спасибо за видео! Немного дополню про мапу, порог называется loadFactor, и он напрямую зависит от initialCapacity. Как было сказано - капасити по умолчанию 16, а лоадфактор 0,75. Это означает, что с 12го элемента мапа будет увеличена вдвое и так в прогрессии.
Ерундой не страдайте, работал уже 10 лет в этой профессии и никогда не пригодилось знание сколько элементов в HashMap. Эти вопросы вообще не нужны. Лучше задавать на конкретных задачах, что умеешь делать, как построить архитектуру и тд.
То есть ты предполагаешь, что человек будет корректно решать поставленные перед ним задачи, не понимая до конца как устроены объекты под капотом, с помощью которых он и будет их решать, тем более мидл?
А как ты будешь отвечать на конкретных задачах, если не знаешь теорию и не знаешь что происходит под капотом? Ты не сможешь оптимизировать код, не поймёшь где случились ошибки... Сеньор на то и сеньор, что умеет во всё вышеперечисленное, а не что умеет решать задачки)
Все зависит от реализации интерфейса. Секунда времени ткнуть мышкой на класс и посмотреть. Древовидные бакетты или списки, сколько элементов по умолчанию... На мой взгляд эти вопросы выпендреж тех кто проводит собес дабы показать, что он что то знает. 😊
Макс, крутой видос, спасибо. 25:14 это кстати пример не deadlock, а livelock. Deadlock был бы, если бы они шли по коридору, встретились, просто встали на одном месте и начали ждать пока проход освободится.
Через 1,5 часа собеседование, смотрел интервью с ребятами, на трудоустройство не рассчитываю, проверю свои знания и будет какой-то опыт. С каналом более углублённо проработал разные вопросы, спасибо
Спасибо большое за разбор, пожелания к видео. Мы поняли к середине видео что собеседование пошло не очень хорошо, поэтому можно было бы и не акцентировать на этом так много внимания, ведь смысловой нагрузки они не прибовляют. Визуализация контента о котором вы говорите было бы очень хорошим дополнением
Макс, спасибо за видео! Про TDD не согласен. Важно понимать концепцию и пробовать)) но на практике она применяется достаточно редко. Одно дело, удобно имплементировать по TDD доменную логику в доменных объектах - объектах где нет зависимостей. И другое дело предвидеть в тестах какие зависимости (сервисы, репозитории) будет использовать юзкеис-класс. В видео ставится = между многопоточностью и реактивщиной, но это разные понятия.
Привет! >> В видео ставится = между многопоточностью и реактивщиной, но это разные понятия. Не знаю где это усматривается из видео. Поскольку аналогии или эквивалентности нет и речи об этом идти не может. Спасибо за фидбек и твой технический коммент))
Классно рассказываешь! Было бы круто с какими то визуальными примерами, не подробное копания для изучения, а чисто увидеть код в той же идее. Не презентация никакая , просто чтоб нормально вспомнить как выглядит))
@Jetbulb Сделайте, пожалуйста, видео с highlight'ми из предыдущих видео, например "как правильно отвечать на вопрос, что такое "объектно ориентированное программирование" или просто нарезку хороших ответов.
Привет, Макс. Мне кажется, пока ты работаешь разрабом в тебе умирает очень крутой ведущий. Скандалы, интриги, расследования. Невыдуманные истории о которых невозможно молчать...
@@Jetbulb Как можно сравнивать ИТ с ведущим. Почитай как строили первые ЭВМ. Как запускали людей в космос. Все достижения современности были бы невозможны без автоматизации вычислений, роста вычислительной мощности и развития алгоритмов. Ты, может быть, утонул в будничной рутине или выбрал не то направление, но профессия у тебя точно самая интересная из доступных в наше время. Ведущий - это говорящая голова, при всем уважении к хорошим ведущим.
Редко пишу комменты, но тут не могу пройти мимо :) сам ответил примерно на половину вопросов, еще о четверти в курсе) рубрика годная, вопросы актуальные, было интересно послушать. Большое спасибо 👍
Разница между джуном и мидлом - в опыте работы. Джун знает в теории и немного пет- практики, а мидло сталкивается на практике с этими знаниями + ускоренном темпе ознакамливается с действующим приложением. (кафка, рэббит, проекции, предикаты, критерия, кэши первого - второго уровня, лэйзи лоадинг + эксепшен, интегрейшен флоу, разные джобы, мапперы и проблемы с маппингом, перформанс проблемы, пути их решения, поиск ботлнеков и их решения, саппорт реквесты - работа с бизнес флоу, работа с внешними системами, если повезёт, то дадут ещё и облака потрогать)
Макс, спасибо! Полезный выпуск. 31:45 - Расскажите, кто имел опыт использования или видел в бизнес коде скоупы request, websocket, application, session? Я за первый год работы ни разу не встречал. Прототайпы встретил только недавно - по всей видимости используются крайне редко.
Планируется)) Все по очереди. Сейчас прошло голосование в ТГ и явно коммуна хочет видеть что-то про реактив. Что ж, этому быть и значит будем готовить материал.
18:12 Бакетов 16??? Бакет - корзинка с Node-ми, элементами коллекции. И на этой корзинке инвентарный номер в виде вычисленного хеша. Сколько возможных вариаций хеша, столько и бакетов ("в принципе есть"). Хеш у HashMap это int это 4 байта, то бишь 2 в 32 степени. Столько теоретически максимально бакетов у коллекции HashMap. Но используются только беззнаковые int, поэтому реально половина. А значение 16, о котором вы говорите как о количестве бакетов (а сколько этих бакетов в принципе есть), это просто начальное их значение выделенное в памяти после инициализации коллекции. Ну это 16 никак не связано с понятием бакета, как можно подумать у вас. PS. threshold ??? Вы точно собеседовали на уровень мидла. :-)) Путаете threshold и loadFactor, это оно 0.75 threshold измеряется как capacity * loadFactor (к слову, это параметры конструктора HashMap) 19:07 "числа я сам в голове не держу" :-) зачем эти детали реализации мидлу? Он должен знать как пользоваться коллекциями и в общих чертах когда какую применять. А не числами забивать голову: static final int TREEIFY_THRESHOLD = 8; static final int MIN_TREEIFY_CAPACITY = 64; 19:56 Нет никакого контракта между equals и hashCode. По hashCode вычисляется хеш и извлекается соответствующий бакет. А дальше идет работа с самим бакетом и там сравнивают ключ уже методом equals. Потому что equals дает точное сравнение, а хеш - это псевдоуникальное распределенное по емкости хеша значение. 22:08 "неправильно" Вы имеете в виду, что он использует HashMap не избегая коллизий? Потому что основной упор в ваших вопросах был на коллизии :-) А какие бы вы дали рекомендации, чтобы избегать коллизий? 28:35 "Какие есть проблемы Future?" Опачки, метод get() - ожидающий ответа от вызванного потока блокируя текущий - это проблема??? А я думал, что это основной функционал этого интерфейса. Он ждет завершения запущенного потока, это проблема? Это его функция! 29:25 почему это вся многопоточность вдруг выродилась в линейное исполнение? Какие это много потоков блокируют друг друга??? Работать может куча потоков, даже этот остановившийся поток может создать пул потоков фабрикой ExecutorService и все они будут работать. Ждать будет только тот поток, который был сознательно и специально остановлен программистом, которому в этой точке данного потока нужен результат работы запущенного потока/потоков и он его ждет методом get интерфейса Future. По вашему, многопоточность - это когда все крутится без остановки??? Управление потоком и взаимодействие потоков - это то, чем занимается Future. 30:18 Все что нужно было бы рассказать об InterruptedException - это не что поток был прерван в процессе ожидания (почему собственно ожидания? ожидания чего? вы про блокировку? поток могут остановить просто потому что кино кончилось у JVM или кто-то решил, что ресурсы нужны, тот же Future, контролирующий поток, сказал ему cancel). Все, что нужно было сказать об InterruptedException - это то, что поток вежливо просят обработать это исключение, последнее в его жизни и корректно завершиться. Вот главное, что нужно знать про InterruptedException. А его почему-то любят ловить (потому что надо по контракту - ибо checked exception) и ничего не делать. А нужно как минимум выставлять флаг завершения потока Thread.currentThread().interrupt(); чтобы контролирующие поток объекты могли понять, что он терминирован. 32:23 "Как себя поведет бин prototype в рамках бина singleton?" Что значит в рамках? Является свойством? Используется в методах? В методах будет вести себя как prototype, при каждом запросе бина будет создаваться новый экземпляр. Свойством? Инжектированным через @Autowared - ну тоже будет вести себя как prototype, когда потребуется в это свойство Spring инжектирует опять же новый инстанс бина этого класса. Да, один раз, но не факт, что вы по каким-то причинам не захотите это поведение поменять. Например ваш prototype бин так устроен, что запускает асинхронный процесс. И в основном singleton-е вы обнаружили, что этот вторичный процесс в блокировке висит. Вы терминируете тот процесс и свойство с бином prototype уже в самом singleton объекте инициируете новым бином prototype. 36:50 Уровни изоляции - это конечно главное, и первое что нужно спросить про работу с БД. Вы назвали некий уровень изоляции "нонрепитэбл рид", которого не существует, есть феномен неповторяющегося чтения, с которым борется уровень изоляции "repeatable read". Ну не суть, оговорка. Главное, вы так говорите о проблемах, как будто они существуют сами по себе и уровни изоляции с ними борются. Это в корне не верная постановка вопроса. Есть определенные уровни изоляции транзакций, определенные стандартном SQL, которые работают на балансе: наличие феноменов/скорость. То есть уже сами стандартом изоляции эти все феномены перечислены. Они часть стандарта. И дело разработчика выбрать на каком уровне изоляции задача должна работать, и получать соответствующую скорость и наличие соответствующих феноменов. Не изоляции придумали, чтобы бороться с феноменами. А определили стандарт из уровней изоляции транзакций с компромиссом документированных феноменов и скорости.
Если честно, этот комментарий выглядит как набор придирок. Автор про Фому, а вы про Ерему. Суть видео - показать, какие вопросы бывают на собеседовании и что ждёт интервьюер, а не устроить конкурс, кто лучше знает детали
@@dmitryrakov2795 Здесь человек задаёт весьма специфичные вопросы и с умным видом на них отвечает. Только в ответах полно неточностей, которые просто вводят в заблуждение Я согласен с автором поста. Меня тоже повеселили "проблемы с Future". Плохо рассказано про изоляции. Не сказано, что есть уровни изоляции по стандарту, но, например, в PostgreSQL они немного отличаются из-за MVCC. В конце был сделан вывод, что SERIALISABLE какая-то панацеяот всех проблем, хотя, например, в постгре этот уровень приводит к новым ошибкам. Про блокировки - тоже сказаны только какие-то общие фразы, ни слова про ACCESS_EXCLUSIVE и тп
Спасибо за видео, сам сейчас готовлюсь к. собеседованиям, было полезно. Но некоторые вопросы показались довольно странными. Например, про количество каких-то там бакетов (или их размер) в HashMap. Во-первых, это всего лишь детали реализации и полагаться на них и заострять на них внимание программисту не положено (т. к. это зависит от реализации JVM под конкретную платформу). Во-вторых, это больше похоже на какие-то вопросы, изучаемые зубрежкой специально для собеседований и нигде не нужные на практике, т. е. бесполезные знания, которые благополучно забудутся через неделю после устройства на работу, Ну, или может быть они и нужны, но в очень узком кругу задач, где ты и сам скорее всего реализуешь свою HashMap, если производительность настолько критична. Мне кажется, что лучше спрашивать кандидатов в целом про умению выстраивать абстракции и использовать какие-то принципы или паттерны, нежели про такие мелочи. А то потом такие "эксперты" по языку такие макароны накатают, что после них хоть заново переписывй. Вроде умные ребята, но свой код правильно организовывать совершенно не умеют. Сам я никогда не проводил собеседования, поэтому опыта у меня в этом можно сказать не очень много, но глядя на некоторых коллег, с кодом которых мне приходилось работать, мне кажется это более правильный подход. )
я для себя понял что устраиваться на работу и работать это 2 разные вещи. когда готовишся к интервью можно заыть чем ты там занимался и просто гуглить что спрашивают на интервью и учить. после трудоустройства можно выдыхать и все это успешно забывать, а потом по новой учить)) я часто ради прикола спрашиваю знакомых синьоров и тимлидов и про хэшмапу и про SOLID - большинство не знают)) а я знаю, и при этом они более крутые девелоперы чем я
Ну вот да, тоже возникает такое чувство. Работаю джавистом уже три года, и для меня непосредственная работа и собеседования это два разных мира. Да, время от времени я сталкиваюсь с ситуациями, когда мне штуки из коллекций стоит вспомнить, если я неправильно использую хешмапу с ключом - объектом, то нужно вспомнить, что метод хеш стоило бы и переопределить.. но это настолько фундаментальные знания, что помнить их досконально не имеет смысла, это гуглится за 30 секунд, и дальше ты пишешь хороший код. Несомненно специалист должен иметь ввиду что он и когда использует... Но как по мне на этом моменте достаточно знать, какие виды имплементаций мапы существуют, сделать фичу, а потом проверить, все ли исправно работает на данных. Таких мелочей может быть миллион и за всеми никогда никому не уследить
Поведение Safe Point в Nested транзакции, не ясно когда и в каком месте он должен создастся чтобы к нему откатится? Я так понимаю транзакционность методов на выполнение всех операций внутри него атомарна, либо выполнятся все либо не выполнятся, а в Nested мы дополнительно через Safe Point указываем до какого места откатится?
Спасибо за видео, очень нравится этот формат!) Про пример deadlock, в коридоре с двумя людьми, если они будут отходить постоянно, это же уже Livelock?)
Я вот что вам скажу, юноши. Я работаю разработчиком уже 20+ лет, много разных проектов за плечами включая пару Spring backends. На СпринхУ как вы выражаетесь 😆.Дык вот. Я бы это собеседование не прошёл. Засыпался бы в самом начале на list и set. Ну не помню я на вскидку кто там чем backed up в Java! Однако в реальной жизни вспомнить это занимает 3 секунды - просто глянув в документацию. Так что собеседования эти ваши туфта - какой-то клуб Что Где Когда 😆. Дайте кандидату реальную задачу и время, а потом посмотрите как он с ней справится. Изи, йопта
Может прийдете к нам на собеседование и порешаем задачки?) Полагаю, что всем будет очень интересно посмотреть на опыт разработчика с большим стажем и как он подходит к решению технических заданий
@@DemonCrit друг мой, за 20+ лет было много разных "баз" чтобы выучить. Причём самому, а не в универе с преподами. Или ваше поколение реально рассчитывает сесть на Java со СпринхОм и скакать 🤠только на этом всём все 20 лет? Или вот ещё этот ваш бесячий дебильный сленг: джуны, мидлы, сеньоры и блять, куда ж без них, лиды 🤮😂
Листы, сеты и мапы есть в java более 25 лет уже, это максимально базовая база, если Вы этого не знаете, с большой долей вероятности данная Вам задача будет решена при помощи изобретения велосипедов и с критическими проблемами дизайна, непригодная к эксплуатации и поддержке. Я пишу на джаве примерно с 2010, и вот со стримами, которые использую постоянно до сих пор порой подсматриваю в документацию и это не супер в плане перформанса, тем более стримы в джаве 10 лет уже, но лист, ЛИСТ И СЕТ, как такое вообще может быть
Насколько мне известно, «одеревенение» списка в бакете происходит не только при переваливании количества нод за 7, но и при условии что число бакетов больше 64
TDD - классная штука. Я с ней сталкивался и кое что делал по ней. Есть только один ОЧЕНЬ ВАЖНЫЙ момент: это было не на работе. Поэтому если на собеседовании меня спрашивают про TDD, то с вероятностью 80% это чисто для выноса моего мозга, а не потому, что в проекте реально это используется.
Не двигаемся мы в мир реактивщины, учитывая что уже в следующем LTS релизе может быть project loom зарелизен. Достоточно посмотреть количество вакансий с реактивным стеком
Про оптимистичные-пессимистичные блокировки не совсем корректно у тебя. Ты говоришь, что пессимистичная блокировка - это блокировка на уровне базы, а оптимистичная - на уровне приложения. Но это не так очень часто, так делить некорректно. Например, в PostgreSQL уровень serializable работает на оптимистичных блокировках через MVCC. Опять же оптимистичную блокировку часто делают именно на уровне БД - прямо в записи делают отдельное поле "version" и работают с ним, а не хранят его в стейте приложения. Т. е. уже почти "на уровне базы". Те же пессимистичные блокировки можно сделать похожим образом - например, тот, кто хочет захватить ресурс, делает в специальной таблице запись. Остальные перед тем как этот ресурс захватить, проверяют наличие записи в таблице, и если там она есть, то доступ к ресурсу для них заблокирован. Главное отличие пессимистичных и оптимистичных блокировок в том, что пессимистичные блокируют ресурс, а оптимистичные нет. Т. е. в случае пессимистичной блокировки мы обязаны перед тем как получить доступ к ресурсу дождаться снятия блокировки, а в случае оптимистичной наоборот - мы узнаём, что ресурс заблокирован только по результату нашей попытки изменения. Пессимистичная выгодней там, где часто происходит конкурентный доступ к одному ресурсу, оптимистичная - где конкурентность ниже, и где важнее скорость вставки и важно не блокировать ресурс.
Что за вопрос про аннотацию Transactional при наследовании? Зачем такие вопросы задавать? Вы реально наследуете один сервис от другого? Имхо, вопрос из серии повыпендриваться и завалить кандидата.
Лично я не часто делаю использую наследование в связке транзакциями. Однако, такое встречается очень часто на разнообразных проектах. Как себя будет вести транзакция в таких условиях - крайне важно.
Очень часто жизненный цикл разработки сервиса начинается с разработки публичного API (интерфейсы, абстракции и т.д.), потом уже пишутся конкретные имплементации. Так вот в публичном API и хочется по максимуму описать контракт разрабатываемого сервиса. Это я про Вашу фразу "Вы реально наследуете один сервис от другого?" - не один от другого, а разные имплементации одного сервиса в зависимости от требований и условий применения, например, "когда луна в Козероге" нам нужна файловая реализация хранилища фотографий, а "если пользователя зовут Елена" уже БД.
@@kolyuchkin кажется, ваши примеры про другой слой - слой доступа к данным. Транзакции же обычно применяются на уровне сервисов. И вроде бы достаточно знать, как поставить аннотацию над методом в реализации сервиса, что такое propagation, когда использовать readonly, и что Transactional не работает при вызове метода внутри сервиса.
Еще небольшая штука с Хэшмап и преобразованием листа в красно-чёрное дерево. 1. При удалении элементов мапа может обратно дерево превратить в лист (по умолчанию 6). 2. Есть минимальный лимит при котором мапа вообще будет превращать лист в дерево (по умолчанию 64). + Был бы хороший вопрос о ребалансе, e.g. что это O(n) операция, которая должна пройтись по всем парам ключ-значение в мапе, пересчитать хэши от ключей и "перетасовать" значения.
Снова линейное время доступа в мапе)) ну не может такого быть начиная с восьмой версии Java. У хэшмапы есть два варианта временной сложности, константная и логарифмическая, линейной нет и смотреть тут нужно не только на мапу, но и на само определение временной сложности алгоритмов, подсказка - ее еще называют ассимптотической.
Так до перехода листа в дерево в бакете при неоптимальной реализации хэшкода у нас мапа работает как линкед лист, и соответственно сложность вставки элемента будет О(n), так как нам надо пробежать по всем элементам для проверки equals
@@agent_yaro не будет, допустим в бакете у нас стабильно есть коллизии, количество элементов попадающих в каждый бакет при этом не превышает 8 и в среднем пусть будет 7. Для любого количества элементов, будь то тысяча, миллион, миллиард, временная сложность доступа будет O(7*1), а как мы знаем, множитель не меняет вид зависимости и отбрасывается, в итоге получаем O(1).
@@DenisNovysh в том-то и дело, что у нас количество элементов в бакете превышает 8, и перехода в дерево нет, пока суммарно элементов 64 не будет, поэтому пока элементов от 1 до 64 у нас сложность О(n)
@@agent_yaro при маленьких значениях n временная сложность не показатель эффективности алгоритма, например у нас есть алгоритм имеющий 10*n операций и алгоритм n*n операций, но мы знаем, что значений может быть максимум 3, в результате у как бы лучшего алгоритма с линейной сложностью будет 30 операций, а у худшего 9, так какой алгоритм лучше? А теперь обернем это все в цикл m, n ограничено некоторой константой и O(n*m) вырождается в O(m), то же самое произойдет с хэш мапой, если количество элементов не превышает 64, то помещая во внешний цикл мы получим не O(n*m), а O(64*m), что соответствует просто O(m).
Тут ещё важно добавить про уровни изоляции транзакций, что чем ниже уровень изоляции транзакции, тем быстрее они работают, потому что меньше механизмов блокировок задействовано. Если у вас высоконагруженое приложение, и в некоторых местах, если конечно такие есть, можно пожертвовать изоляцией в пользу быстродействия, то почему бы и нет?
Иногда необходимо время чтобы открыть глаза, увидеть правду и сказать о ней. Но справедливости ради, 9 лет назад на территории Украины не было открытого нападения соседнего государства (исключение Крым)
Если кратко, TreeSet под капотом хранит TreeMap. Соответственно, equals+hashcode должны быть согласованы для работы с ключами (сортировка, поиск). Как это завещает TreeMap. Самый верный вариант для изучения этой темы: - "просто открыть класс и пройтись строка за строкой." Тогда на долго отложится это знание и появится понимание. По крайней мере именно это мне помогло.
"@Transactional создает обертку с try catch " - возможно блок трай кетч там и присутствует, но суть не в этом. суть именно в создании транзакции на уровне бд.
Я бы в образовательных целях добавил к этому что обертка это прокси класс, что это паттерн, реализуемый при помощи аоп и он изящно разносит бизнес логику и рутинные операции а ля открытие/закрытие транзакции
Привет! У тебя есть видео про SDET? Сейчас прохожу bootcamp и голова плавится, представляю что с девелопарами происходит. Это видео реально интересно посмотреть.
работаю долго на первой работе скоро будет почти 15 лет... получается больше как поддержка базы данных и данной системы (отчеты всякие большую часть занимают) не скажу что совсем ничего не интересовался интересовался, читал книги по c++, java, ковырялся в разных проектах (unreal engine, прочие) делал приложения на android где backend на php простенький писал теперь думаю работу другую найти уже как java-разработчик придется идти как начинающий, но даже тут зарплаты могут быть выше чем у меня сейчас по сравнению с c++, в java порядок считай до всяких обновлений в c++ там был ужас, что с stl, что с прочими стандартными библиотеками понятно что с++ нужный язык, на нем саму jvm написали и прочее но он обычно востребован в серьезных конторах, а их немного уже тошнит ходить на работу и этим заниматься... а найти новую еще придется пытаться искать сейчас ковыряю в VueJs, Spring Boot
хороший опыт, всем ребят советую сдать для начала OCP17 экзамен по java, а потом получать "коммерческий" опыт. Я на собственном примере понял , что Oracle экзамен это лучшая подготовка к собеседованию и даёт не поверхностное пониманиe того как работает java. Всем мира )
не уверен, но при простой коллизии нода вроде не перестраивается в дерево. Там есть лимит на количество элементов в бакете (вроде 8) и общее число бакетов (вроде 32). 2 этих условия с логическим и. Порог же вроде loadFactor? Еще по тримапе интересный вопрос можно задать: как в тримапу положить объект, который не реализует comparable и мы не передаем компаратор? На как тогда будут сортироваться ключи?
Здравствуйте, подскажите: я не знал, что тремпель - это вешалка, но пользовался им; Вопрос: если я не знал термина полимлрфизм, но в работе использовал механизм так называемый … то это говорит, что спрашивать термин нет смысла? Спасибо
Привет ))) Вопрос очень неоднозначный и холиварный, но попробую ответь: «Если человек успешно применят какой-либо прием и даже не подозревает об этом. То это круто! Для меня это сигнал, что человек думает и может сотворять. Однако, есть и другая сторона медали. Сложно назвать человека инженером, если он применяет что-то фундаментальное из своей отрасли, но сам того не подозревая» Это тонкая грань. Одно и второе имеет место быть и вовсе не может характеризовать человека как плохо сотрудника. Это вопрос конкретной позиции и требований выдвигаемых этой позицией.
@@Jetbulb Что можно порекомендовать отвечать, когда уже долго работаешь и теория выветрилась? Так не хочется повторно учить слова, а читать знакомое претит
@@for_find_me006 Как говорится: "Рыбак рыбака видит из далека". Так и тут. Опыт видно из далека. Человек с опытом уже говорит и обосновывает вещи иначе. Я к тому, что притворство очень легко изобличить. Если не знаешь, то это будет видно практически сразу. Дело же не только теории и терминологии
@@Jetbulb Якщо, є три value наприклад: object1, object2, object3. То при колізії їх ключів, порядок в бакеті буде object1 -> object2 -> object3. Так? Бо якщо додавати на початок списку, то виглядає так, наче порядок має бути такий object3 -> object2 -> object1
про @Transactional: а как же TransactionInterceptor, TransactionManager, EntityManager причем тут прокси и тд? Разве не этого ждешь при вопросе, как работает?
Я бы хотел попробовать себя на собеседовании и получить рекомендации, что нужно подтянуть и что вообще делать. Стоит ли мне пытаться искать работу или еще поучиться.
Мая, приветствую)) Точно буду занят текущей группой до НГ. А дальше еще не знаю. Лучше это уточнять в учебном отделе. Они ведают планированием) Спасибо за интерес. Балуете меня ☺️
Очень странный собес на мидла. Обычно мало вопросов по джаве, но много по сопутствующим фреймворкам и технологиям. Около 30 собесов за полгода уже прошёл 🥴
У разных компаний разные собеседования. Есть кто даёт сразу задачи на алгоритмы и нужно писать код сразу и быстро. Кто-то спрашивает по брокеры сообщений (какие есть, основные отличия), про NoSQL, docker, helm, Kubernetes. Другие дают задачи на проектирования и т.д.
Посмотрел ужн кучу мок интервью, и думаю, что ответил бы на большинство вопросов верно. Но меня всегда удивляют такие вопросы на собеседованиях. Всегда живу с мыслью о том, что учить это надо только для того, чтобы пройти собеседование на случай, если будут попадаться неадекватные интервьюверы. В работе эти знания никогда не пригодятся или их польза стремится к нулю...
Если мы говорим об общем случае (в Java возможно сценарий не воспроизводится) для цикла в графе ожиданий (deadlock) достаточно одного потока: Например: mutex_lock(m); mutex_lock(m);
45:28 Послушал про оптимистичную и пессимистичную блокировку. Улыбнуло. Объясню вам на пальцах, чтобы вы других не вводили в заблуждение. Смотрите. Прежде всего блокировка нам нужна только когда мы что-то меняем. И блокировка нужна, чтобы измененные данные сохранили свою целостность. Не были утрачены в какой-то части в результате наложившихся параллельных изменений. Никакая блокировка не должна запрещать другим читать данные (если не мегаспециальные сценарии). Это касается только функционала изменения данных. Например, открыли на редактирование какой-то документ. Поредактировали и сохранили.
Что такое оптимистическая блокировка и почему она так называется. Оптимистическая блокировка берет данные в работу на изменение и никому не запрещает взять эти же данные на изменения параллельно. Это такие оптимисты, которые надеются успеть изменить документ и сохранить его пока никто не успел взять этот документ на изменение. Далее, кто первый встал того и тапки, кто первый записался в базу данных, тот молодец, а второй "неудачный оптимист" получит отлуп по блокировке, если механизм блокировки вообще есть. Один из вариантов реализации оптимистичной блокировки является версионирование данных. Каждый entity имеет в БД поле с номером версии, он меняется в БД когда кто-то изменил этот блок данных entity. Соответственно при попытке записаться сравнивается версия исходная с которыми данные получены и версия на момент записи. И если они отличаются, то отказ. За это отвечает та самая аннотация @Version. Это работает как видите и на уровне приложения, и на уровне БД.
Теперь, пессимистичная блокировка. Тут работают пессимисты, они не действую по принципу "авось никто не успеет поменять документ, пока я тут его же меняю", они берут данные в работу на изменение и запрещают другим брать эти же данные на изменение, читать - пожалуйста. Но брать на изменение второму не дадут, жди пока первый разблокирует данные. Это гарантирует первому спокойное сохранение какого-то очень важного документа, важного начальника, который не будет повторять дважды и бегать за уведенными тапками. Для такого типа блокировки где-то, в БД или в приложении выставляется признак, что данные взяты на изменение, кем, когда. И все остальные (жаждущие изменить, читать - пожалуйста ) ждут, механизм может поддерживать автоматическую разблокировку через таймаут. Если кто-то взял документ на изменение и ушел в декретный отпуск, а другим его нужно изменять.
Оптимистичная блокировка хороша, когда данные не критичны, можно повторить изменения. Получил отлуп, перечитал данные и внес в новую версию уже свое, если вообще потребуется, а то может коллега уже все прописал. И обычно используется когда нет высокой конкуренции. Главное, она не блокирует работу с документом на изменение, она блокирует прием результата изменений, если кто-то успел документ изменить. Плюс: бери документ на изменение кто хочет, кто первый успел, тот молодец. Минусы: при блокировке приходится перечитывать новую измененную версию и повторять всю работу по изменению снова.
Пессимистичная блокировка нужна когда данные оперативно меняются в условиях высокой конкуренции или когда важный документ, который переделывать повторно трудозатратно. Плюс: все что вы изменили гарантированно примется. Минусы: остальные документ изменить не могут пока вы его "держите" на изменение.
Возможны гибридные варианты стратегии блокировки. Например, какие-то типы документов работают в оптимистической стратегии, какие-то особо важные в пессимистической. Или даже так: первые N часов/минут документ работает в режиме пессимистической блокировки, потом переключается в режим оптимистической. Тогда достигается комбинация положительных сторон двух стратегий и определенный компромисс недостатков (но это уже не про Spring)
очень круто все расписали. спасибо!
Очень здорово объяснено. Спасибо!
Спасибо! А то я уже начинал сомневаться в себе)))
Для чего тогда вообще нужна оптимистическая блокировка, если она точно так же не позволяет одному что-то менять, если меняет и другой? Зачем тогда вообще давать доступ, что-то делать, если будет откатываться всё равно?
@@user-iy1zv9ej1d Применение оптимистичного параллелизма способствует повышению производительности благодаря тому, что не требуется блокировка записей, которая требует дополнительных ресурсов сервера. Кроме того, для блокировки записей требуется постоянное соединение с сервером базы данных. При использовании модели оптимистичного параллелизма такая необходимость отсутствует, поэтому соединения с сервером можно применять для обслуживания большего количества клиентов за меньшее время.
Спасибо огромное за Ваш труд и время потраченные на создание канала. Полезная информация для подготовки к собеседовании, приятная подача.
Особенно радует текст в начале видео!
Спасибо за данный ролик. Много что узнал нового для себя. Как раз готовлюсь к собесам :)
спасибо за старания, все супер, смотрится на одном дыхании, все понятно и интересно объясняется. Полезное и приятное время препровождение )
Спасибо огромное за столь большой объем качественной информации!
Очень познавательно, Макс, спасибо! Много нового для себя подчерпнул особенно про аннотацию transactional, но просмотрев, понял, что много вещей будучи джуном уже знаю, чем был приятно удивлен, еще раз спасибо, продолжай в том же духе, хотелось бы еще хотя бы 1 пример интервью (или такого же формата как это видео) вопросов мидлу.
Скоро будет видео на синьорскому собеседованию )))
Материал собирается.
Спасибо за твой фидбек ☺️🙏🏻
@@Jetbulb круто) буду ждать
Громадное спасибо за подобный контент! Во-первых, это невероятно интересная информация, во-вторых - необычайно полезная для всех!
Автору канала успехов!
Контент топчик! Максон спасибо :) Очень много интересного!
Меня на джуна сильнее спрашивали, это было 2 года назад :)
Спасибо. Полезно. Ещё раз пересмотрю
Спасибо за видео! Немного дополню про мапу, порог называется loadFactor, и он напрямую зависит от initialCapacity.
Как было сказано - капасити по умолчанию 16, а лоадфактор 0,75. Это означает, что с 12го элемента мапа будет увеличена вдвое и так в прогрессии.
Сейчас такое у джунов спрашивают) спасибо за видео, хорошо объяснил ответы на вопросы
Спасибо за пример собеседования, очень содержательно.
спасибо за такого рода видео, очень много новых нюансов узнаю)
Очень круто! Спасибо за разбор интервью - это действительно полезно
Даже для джуна это интересно. Круто. Спасибо за информацию)
Спасибо за качественные и полезные выпуски 😊
Ерундой не страдайте, работал уже 10 лет в этой профессии и никогда не пригодилось знание сколько элементов в HashMap. Эти вопросы вообще не нужны. Лучше задавать на конкретных задачах, что умеешь делать, как построить архитектуру и тд.
То есть ты предполагаешь, что человек будет корректно решать поставленные перед ним задачи, не понимая до конца как устроены объекты под капотом, с помощью которых он и будет их решать, тем более мидл?
А как ты будешь отвечать на конкретных задачах, если не знаешь теорию и не знаешь что происходит под капотом? Ты не сможешь оптимизировать код, не поймёшь где случились ошибки...
Сеньор на то и сеньор, что умеет во всё вышеперечисленное, а не что умеет решать задачки)
Все зависит от реализации интерфейса. Секунда времени ткнуть мышкой на класс и посмотреть. Древовидные бакетты или списки, сколько элементов по умолчанию... На мой взгляд эти вопросы выпендреж тех кто проводит собес дабы показать, что он что то знает. 😊
@@alias77799 ты читал вообще?
Не пригодились знания "сколько количество элементов в хэшмапе" != "не понимает как устроены объекты под капотом"
@@Happy-s8l1c это ты читал вообще мой коммент или просто что-то отписать?
По больше бы таких видео))
Именно про миддлов особенно лайв кодинг))
Макс, крутой видос, спасибо. 25:14 это кстати пример не deadlock, а livelock. Deadlock был бы, если бы они шли по коридору, встретились, просто встали на одном месте и начали ждать пока проход освободится.
Отличное замечание))
Спасибо 👍
И за фидбек в том числе
Через 1,5 часа собеседование, смотрел интервью с ребятами, на трудоустройство не рассчитываю, проверю свои знания и будет какой-то опыт. С каналом более углублённо проработал разные вопросы, спасибо
Как собеседование прошло?
И как? Получилось?
Человек видимо уже работает, нету времени отвечать)
Спасибо большое за разбор, пожелания к видео.
Мы поняли к середине видео что собеседование пошло не очень хорошо, поэтому можно было бы и не акцентировать на этом так много внимания, ведь смысловой нагрузки они не прибовляют. Визуализация контента о котором вы говорите было бы очень хорошим дополнением
Спасибо за видео! Каждый раз узнаешь что-то новое или повторяешь то что забыл
Просмотрел, сделал конспект ))) Спасибо!
Макс🖐 Спасибо за годный контент👍👍👍
Разумеется, я посмотрел видео, и, соответственно, поставил лайк.
Блин, ты очень классный рассказчик. Я бы с удовольствием послушал про Spring от тебя , прям love)
Спасибо за фидбек))) Это лучшая награда.
Кстати, у нас есть плейлисты про спринг. Правда там не много видео, но это временно.
Макс, спасибо за видео!
Про TDD не согласен. Важно понимать концепцию и пробовать)) но на практике она применяется достаточно редко. Одно дело, удобно имплементировать по TDD доменную логику в доменных объектах - объектах где нет зависимостей. И другое дело предвидеть в тестах какие зависимости (сервисы, репозитории) будет использовать юзкеис-класс.
В видео ставится = между многопоточностью и реактивщиной, но это разные понятия.
Привет!
>> В видео ставится = между многопоточностью и реактивщиной, но это разные понятия.
Не знаю где это усматривается из видео. Поскольку аналогии или эквивалентности нет и речи об этом идти не может.
Спасибо за фидбек и твой технический коммент))
Классно рассказываешь! Было бы круто с какими то визуальными примерами, не подробное копания для изучения, а чисто увидеть код в той же идее. Не презентация никакая , просто чтоб нормально вспомнить как выглядит))
@Jetbulb Сделайте, пожалуйста, видео с highlight'ми из предыдущих видео, например "как правильно отвечать на вопрос, что такое "объектно ориентированное программирование" или просто нарезку хороших ответов.
Спасибо, про уровни изоляции транзакций было полезно
Про базы и транзакции - класс, интересно
Дякую, за цікавий та корисний контент 🙂
Респект 👍 🇺🇦
Очень круто. Было очень интересно)
Спасибо!
Но прошу, выравнивай звук на отбивках. Очень жестко по ушам бьет.
Привет, Макс. Мне кажется, пока ты работаешь разрабом в тебе умирает очень крутой ведущий. Скандалы, интриги, расследования. Невыдуманные истории о которых невозможно молчать...
Я походу не ту профессию выбрал)))
@@Jetbulb Как можно сравнивать ИТ с ведущим. Почитай как строили первые ЭВМ. Как запускали людей в космос. Все достижения современности были бы невозможны без автоматизации вычислений, роста вычислительной мощности и развития алгоритмов. Ты, может быть, утонул в будничной рутине или выбрал не то направление, но профессия у тебя точно самая интересная из доступных в наше время. Ведущий - это говорящая голова, при всем уважении к хорошим ведущим.
@@doh2535 часто ведущие не просто говорят, а ещё и материал программы сами готовят, разбираются в предмете.
@@doh2535 чтобы понять,что ведущий это не просто голова, рекомендую найти и посмотреть передачи региональных тв или студенческих
Просто талантливый человек талантлив во всем)
Спасибо, Макс. Звук лучше стал )
Ага. Микро подъехал))
Спасибо за фидбек
Респект 👍
Здравствствуйте Максим! Расскажите, пожалуйста, про профайлинг, бенчмарки (JMH) на Java. Спасибо за видео!
Привет!
Хорошая тема. Недавно с коллегой обсуждали один пост про JMH.
Спасибо за наводку и фидбек 👍
Отличное видео! Молодец!
Побольше бы таких интервьюверов как Макс
Спасибо за видео.
Редко пишу комменты, но тут не могу пройти мимо :) сам ответил примерно на половину вопросов, еще о четверти в курсе) рубрика годная, вопросы актуальные, было интересно послушать. Большое спасибо 👍
Большое спасибо за отзыв)) Лучшая награда!
Респект!
В моментах очень высокомерно , при всем том , что на некоторые вопросы товарищ сам отвечает посредственно)
Постепенно разница между джуном и мидлом размывается. Ждем синьеров с двумя годами опыта.
Господи! Причём тут год или два! Ты - идиот!
Разница между джуном и мидлом - в опыте работы. Джун знает в теории и немного пет- практики, а мидло сталкивается на практике с этими знаниями + ускоренном темпе ознакамливается с действующим приложением. (кафка, рэббит, проекции, предикаты, критерия, кэши первого - второго уровня, лэйзи лоадинг + эксепшен, интегрейшен флоу, разные джобы, мапперы и проблемы с маппингом, перформанс проблемы, пути их решения, поиск ботлнеков и их решения, саппорт реквесты - работа с бизнес флоу, работа с внешними системами, если повезёт, то дадут ещё и облака потрогать)
Макс, спасибо! Полезный выпуск. 31:45 - Расскажите, кто имел опыт использования или видел в бизнес коде скоупы request, websocket, application, session? Я за первый год работы ни разу не встречал. Прототайпы встретил только недавно - по всей видимости используются крайне редко.
Привет!
Встречаются. Хотя все зависит от сложности внутренного устройства приложения.
Я видел несколько раз: Request и Session
Спасибо за фидбек )
Было интересно, спасибо
чёткое видео! спасибо!
Отличная картинка, Макс. Пора еще одну добавить :)))
Ну зачем ты мне про линт рассказал? Вечер потерян как и самооценка :)))))
Классный видос, спасибо :)
P.S. А выпуск по реактивщине не планируется?)
Планируется))
Все по очереди. Сейчас прошло голосование в ТГ и явно коммуна хочет видеть что-то про реактив. Что ж, этому быть и значит будем готовить материал.
18:12 Бакетов 16??? Бакет - корзинка с Node-ми, элементами коллекции. И на этой корзинке инвентарный номер в виде вычисленного хеша. Сколько возможных вариаций хеша, столько и бакетов ("в принципе есть"). Хеш у HashMap это int это 4 байта, то бишь 2 в 32 степени. Столько теоретически максимально бакетов у коллекции HashMap. Но используются только беззнаковые int, поэтому реально половина. А значение 16, о котором вы говорите как о количестве бакетов (а сколько этих бакетов в принципе есть), это просто начальное их значение выделенное в памяти после инициализации коллекции. Ну это 16 никак не связано с понятием бакета, как можно подумать у вас.
PS. threshold ??? Вы точно собеседовали на уровень мидла. :-)) Путаете threshold и loadFactor, это оно 0.75 threshold измеряется как capacity * loadFactor (к слову, это параметры конструктора HashMap)
19:07 "числа я сам в голове не держу" :-) зачем эти детали реализации мидлу? Он должен знать как пользоваться коллекциями и в общих чертах когда какую применять. А не числами забивать голову:
static final int TREEIFY_THRESHOLD = 8;
static final int MIN_TREEIFY_CAPACITY = 64;
19:56 Нет никакого контракта между equals и hashCode. По hashCode вычисляется хеш и извлекается соответствующий бакет. А дальше идет работа с самим бакетом и там сравнивают ключ уже методом equals. Потому что equals дает точное сравнение, а хеш - это псевдоуникальное распределенное по емкости хеша значение.
22:08 "неправильно" Вы имеете в виду, что он использует HashMap не избегая коллизий? Потому что основной упор в ваших вопросах был на коллизии :-) А какие бы вы дали рекомендации, чтобы избегать коллизий?
28:35 "Какие есть проблемы Future?" Опачки, метод get() - ожидающий ответа от вызванного потока блокируя текущий - это проблема??? А я думал, что это основной функционал этого интерфейса. Он ждет завершения запущенного потока, это проблема? Это его функция! 29:25 почему это вся многопоточность вдруг выродилась в линейное исполнение? Какие это много потоков блокируют друг друга??? Работать может куча потоков, даже этот остановившийся поток может создать пул потоков фабрикой ExecutorService и все они будут работать. Ждать будет только тот поток, который был сознательно и специально остановлен программистом, которому в этой точке данного потока нужен результат работы запущенного потока/потоков и он его ждет методом get интерфейса Future. По вашему, многопоточность - это когда все крутится без остановки??? Управление потоком и взаимодействие потоков - это то, чем занимается Future.
30:18 Все что нужно было бы рассказать об InterruptedException - это не что поток был прерван в процессе ожидания (почему собственно ожидания? ожидания чего? вы про блокировку? поток могут остановить просто потому что кино кончилось у JVM или кто-то решил, что ресурсы нужны, тот же Future, контролирующий поток, сказал ему cancel). Все, что нужно было сказать об InterruptedException - это то, что поток вежливо просят обработать это исключение, последнее в его жизни и корректно завершиться. Вот главное, что нужно знать про InterruptedException. А его почему-то любят ловить (потому что надо по контракту - ибо checked exception) и ничего не делать. А нужно как минимум выставлять флаг завершения потока Thread.currentThread().interrupt(); чтобы контролирующие поток объекты могли понять, что он терминирован.
32:23 "Как себя поведет бин prototype в рамках бина singleton?" Что значит в рамках? Является свойством? Используется в методах? В методах будет вести себя как prototype, при каждом запросе бина будет создаваться новый экземпляр. Свойством? Инжектированным через @Autowared - ну тоже будет вести себя как prototype, когда потребуется в это свойство Spring инжектирует опять же новый инстанс бина этого класса. Да, один раз, но не факт, что вы по каким-то причинам не захотите это поведение поменять. Например ваш prototype бин так устроен, что запускает асинхронный процесс. И в основном singleton-е вы обнаружили, что этот вторичный процесс в блокировке висит. Вы терминируете тот процесс и свойство с бином prototype уже в самом singleton объекте инициируете новым бином prototype.
36:50 Уровни изоляции - это конечно главное, и первое что нужно спросить про работу с БД. Вы назвали некий уровень изоляции "нонрепитэбл рид", которого не существует, есть феномен неповторяющегося чтения, с которым борется уровень изоляции "repeatable read". Ну не суть, оговорка. Главное, вы так говорите о проблемах, как будто они существуют сами по себе и уровни изоляции с ними борются. Это в корне не верная постановка вопроса. Есть определенные уровни изоляции транзакций, определенные стандартном SQL, которые работают на балансе: наличие феноменов/скорость. То есть уже сами стандартом изоляции эти все феномены перечислены. Они часть стандарта. И дело разработчика выбрать на каком уровне изоляции задача должна работать, и получать соответствующую скорость и наличие соответствующих феноменов. Не изоляции придумали, чтобы бороться с феноменами. А определили стандарт из уровней изоляции транзакций с компромиссом документированных феноменов и скорости.
Если честно, этот комментарий выглядит как набор придирок. Автор про Фому, а вы про Ерему. Суть видео - показать, какие вопросы бывают на собеседовании и что ждёт интервьюер, а не устроить конкурс, кто лучше знает детали
@@dmitryrakov2795 Здесь человек задаёт весьма специфичные вопросы и с умным видом на них отвечает. Только в ответах полно неточностей, которые просто вводят в заблуждение
Я согласен с автором поста. Меня тоже повеселили "проблемы с Future". Плохо рассказано про изоляции. Не сказано, что есть уровни изоляции по стандарту, но, например, в PostgreSQL они немного отличаются из-за MVCC. В конце был сделан вывод, что SERIALISABLE какая-то панацеяот всех проблем, хотя, например, в постгре этот уровень приводит к новым ошибкам. Про блокировки - тоже сказаны только какие-то общие фразы, ни слова про ACCESS_EXCLUSIVE и тп
Спасибі за точний та остаточний погляд на війну. І величезне дякую за вашу працю. Стежу за вами вже рік, продовжуйте в тому ж руслі)
Дякую за фідбек. Будемо працювати і далі 🇺🇦 🙂
Респект!
А еще можно про vector спросить. Как, вы не знаете, как работает vector? Ай-ай-ай:))
Спасибо за видео, сам сейчас готовлюсь к. собеседованиям, было полезно.
Но некоторые вопросы показались довольно странными. Например, про количество каких-то там бакетов (или их размер) в HashMap. Во-первых, это всего лишь детали реализации и полагаться на них и заострять на них внимание программисту не положено (т. к. это зависит от реализации JVM под конкретную платформу). Во-вторых, это больше похоже на какие-то вопросы, изучаемые зубрежкой специально для собеседований и нигде не нужные на практике, т. е. бесполезные знания, которые благополучно забудутся через неделю после устройства на работу, Ну, или может быть они и нужны, но в очень узком кругу задач, где ты и сам скорее всего реализуешь свою HashMap, если производительность настолько критична.
Мне кажется, что лучше спрашивать кандидатов в целом про умению выстраивать абстракции и использовать какие-то принципы или паттерны, нежели про такие мелочи. А то потом такие "эксперты" по языку такие макароны накатают, что после них хоть заново переписывй. Вроде умные ребята, но свой код правильно организовывать совершенно не умеют.
Сам я никогда не проводил собеседования, поэтому опыта у меня в этом можно сказать не очень много, но глядя на некоторых коллег, с кодом которых мне приходилось работать, мне кажется это более правильный подход. )
я для себя понял что устраиваться на работу и работать это 2 разные вещи. когда готовишся к интервью можно заыть чем ты там занимался и просто гуглить что спрашивают на интервью и учить. после трудоустройства можно выдыхать и все это успешно забывать, а потом по новой учить)) я часто ради прикола спрашиваю знакомых синьоров и тимлидов и про хэшмапу и про SOLID - большинство не знают)) а я знаю, и при этом они более крутые девелоперы чем я
Ну вот да, тоже возникает такое чувство. Работаю джавистом уже три года, и для меня непосредственная работа и собеседования это два разных мира. Да, время от времени я сталкиваюсь с ситуациями, когда мне штуки из коллекций стоит вспомнить, если я неправильно использую хешмапу с ключом - объектом, то нужно вспомнить, что метод хеш стоило бы и переопределить.. но это настолько фундаментальные знания, что помнить их досконально не имеет смысла, это гуглится за 30 секунд, и дальше ты пишешь хороший код. Несомненно специалист должен иметь ввиду что он и когда использует... Но как по мне на этом моменте достаточно знать, какие виды имплементаций мапы существуют, сделать фичу, а потом проверить, все ли исправно работает на данных. Таких мелочей может быть миллион и за всеми никогда никому не уследить
Поведение Safe Point в Nested транзакции, не ясно когда и в каком месте он должен создастся чтобы к нему откатится? Я так понимаю транзакционность методов на выполнение всех операций внутри него атомарна, либо выполнятся все либо не выполнятся, а в Nested мы дополнительно через Safe Point указываем до какого места откатится?
в оракле 20 лет назад наверное токо пессимистичные транзакции знал ибо там на пол часа всего чтива было и никаких изоляций не требовалось
Я ищу работу Java Junior и то без проблем бы рассказал бы о HashMap
Спасибо за видео, очень нравится этот формат!)
Про пример deadlock, в коридоре с двумя людьми, если они будут отходить постоянно, это же уже Livelock?)
Да, там косяк вышел))
Речь шла про Livelock
Спасибо за отзыв))
Боже.. послезавтра собес.. а я залипла на ресничках.. памагите.
Я вот что вам скажу, юноши. Я работаю разработчиком уже 20+ лет, много разных проектов за плечами включая пару Spring backends. На СпринхУ как вы выражаетесь 😆.Дык вот. Я бы это собеседование не прошёл. Засыпался бы в самом начале на list и set. Ну не помню я на вскидку кто там чем backed up в Java! Однако в реальной жизни вспомнить это занимает 3 секунды - просто глянув в документацию. Так что собеседования эти ваши туфта - какой-то клуб Что Где Когда 😆. Дайте кандидату реальную задачу и время, а потом посмотрите как он с ней справится. Изи, йопта
Может прийдете к нам на собеседование и порешаем задачки?)
Полагаю, что всем будет очень интересно посмотреть на опыт разработчика с большим стажем и как он подходит к решению технических заданий
считаю, что за 20 лет такую базу уже можно было выучить
@@DemonCrit друг мой, за 20+ лет было много разных "баз" чтобы выучить. Причём самому, а не в универе с преподами. Или ваше поколение реально рассчитывает сесть на Java со СпринхОм и скакать 🤠только на этом всём все 20 лет? Или вот ещё этот ваш бесячий дебильный сленг: джуны, мидлы, сеньоры и блять, куда ж без них, лиды 🤮😂
Листы, сеты и мапы есть в java более 25 лет уже, это максимально базовая база, если Вы этого не знаете, с большой долей вероятности данная Вам задача будет решена при помощи изобретения велосипедов и с критическими проблемами дизайна, непригодная к эксплуатации и поддержке.
Я пишу на джаве примерно с 2010, и вот со стримами, которые использую постоянно до сих пор порой подсматриваю в документацию и это не супер в плане перформанса, тем более стримы в джаве 10 лет уже, но лист, ЛИСТ И СЕТ, как такое вообще может быть
Качество выпусков заметно улучшилось👍
Насколько мне известно, «одеревенение» списка в бакете происходит не только при переваливании количества нод за 7, но и при условии что число бакетов больше 64
Именно так
не так, за 8
TDD - классная штука. Я с ней сталкивался и кое что делал по ней. Есть только один ОЧЕНЬ ВАЖНЫЙ момент: это было не на работе.
Поэтому если на собеседовании меня спрашивают про TDD, то с вероятностью 80% это чисто для выноса моего мозга, а не потому, что в проекте реально это используется.
А как ты можешь реально проверить, что на проекте TDD не используется?)
@@Jetbulb например, начать в нём работать.
Не двигаемся мы в мир реактивщины, учитывая что уже в следующем LTS релизе может быть project loom зарелизен. Достоточно посмотреть количество вакансий с реактивным стеком
Спасибо, Макс
Про оптимистичные-пессимистичные блокировки не совсем корректно у тебя. Ты говоришь, что пессимистичная блокировка - это блокировка на уровне базы, а оптимистичная - на уровне приложения. Но это не так очень часто, так делить некорректно.
Например, в PostgreSQL уровень serializable работает на оптимистичных блокировках через MVCC.
Опять же оптимистичную блокировку часто делают именно на уровне БД - прямо в записи делают отдельное поле "version" и работают с ним, а не хранят его в стейте приложения. Т. е. уже почти "на уровне базы".
Те же пессимистичные блокировки можно сделать похожим образом - например, тот, кто хочет захватить ресурс, делает в специальной таблице запись. Остальные перед тем как этот ресурс захватить, проверяют наличие записи в таблице, и если там она есть, то доступ к ресурсу для них заблокирован.
Главное отличие пессимистичных и оптимистичных блокировок в том, что пессимистичные блокируют ресурс, а оптимистичные нет. Т. е. в случае пессимистичной блокировки мы обязаны перед тем как получить доступ к ресурсу дождаться снятия блокировки, а в случае оптимистичной наоборот - мы узнаём, что ресурс заблокирован только по результату нашей попытки изменения.
Пессимистичная выгодней там, где часто происходит конкурентный доступ к одному ресурсу, оптимистичная - где конкурентность ниже, и где важнее скорость вставки и важно не блокировать ресурс.
Что за вопрос про аннотацию Transactional при наследовании? Зачем такие вопросы задавать? Вы реально наследуете один сервис от другого? Имхо, вопрос из серии повыпендриваться и завалить кандидата.
Лично я не часто делаю использую наследование в связке транзакциями.
Однако, такое встречается очень часто на разнообразных проектах. Как себя будет вести транзакция в таких условиях - крайне важно.
Очень часто жизненный цикл разработки сервиса начинается с разработки публичного API (интерфейсы, абстракции и т.д.), потом уже пишутся конкретные имплементации. Так вот в публичном API и хочется по максимуму описать контракт разрабатываемого сервиса. Это я про Вашу фразу "Вы реально наследуете один сервис от другого?" - не один от другого, а разные имплементации одного сервиса в зависимости от требований и условий применения, например, "когда луна в Козероге" нам нужна файловая реализация хранилища фотографий, а "если пользователя зовут Елена" уже БД.
@@kolyuchkin кажется, ваши примеры про другой слой - слой доступа к данным. Транзакции же обычно применяются на уровне сервисов. И вроде бы достаточно знать, как поставить аннотацию над методом в реализации сервиса, что такое propagation, когда использовать readonly, и что Transactional не работает при вызове метода внутри сервиса.
Еще небольшая штука с Хэшмап и преобразованием листа в красно-чёрное дерево.
1. При удалении элементов мапа может обратно дерево превратить в лист (по умолчанию 6).
2. Есть минимальный лимит при котором мапа вообще будет превращать лист в дерево (по умолчанию 64).
+ Был бы хороший вопрос о ребалансе, e.g. что это O(n) операция, которая должна пройтись по всем парам ключ-значение в мапе, пересчитать хэши от ключей и "перетасовать" значения.
Прошел несколько собесов на джуна...вопросы абсолютно те же. Незнаю хорошо это или плохо
Мне и на синьора такие же вопросы как в джуновских разборах собесов вопросы задают часто.
Снова линейное время доступа в мапе)) ну не может такого быть начиная с восьмой версии Java. У хэшмапы есть два варианта временной сложности, константная и логарифмическая, линейной нет и смотреть тут нужно не только на мапу, но и на само определение временной сложности алгоритмов, подсказка - ее еще называют ассимптотической.
Так до перехода листа в дерево в бакете при неоптимальной реализации хэшкода у нас мапа работает как линкед лист, и соответственно сложность вставки элемента будет О(n), так как нам надо пробежать по всем элементам для проверки equals
@@agent_yaro не будет, допустим в бакете у нас стабильно есть коллизии, количество элементов попадающих в каждый бакет при этом не превышает 8 и в среднем пусть будет 7. Для любого количества элементов, будь то тысяча, миллион, миллиард, временная сложность доступа будет O(7*1), а как мы знаем, множитель не меняет вид зависимости и отбрасывается, в итоге получаем O(1).
@@DenisNovysh в том-то и дело, что у нас количество элементов в бакете превышает 8, и перехода в дерево нет, пока суммарно элементов 64 не будет, поэтому пока элементов от 1 до 64 у нас сложность О(n)
@@agent_yaro 64 стремится в бесконечность или 64 это константа, надеюсь стало понятно в чем заблуждение?
@@agent_yaro при маленьких значениях n временная сложность не показатель эффективности алгоритма, например у нас есть алгоритм имеющий 10*n операций и алгоритм n*n операций, но мы знаем, что значений может быть максимум 3, в результате у как бы лучшего алгоритма с линейной сложностью будет 30 операций, а у худшего 9, так какой алгоритм лучше? А теперь обернем это все в цикл m, n ограничено некоторой константой и O(n*m) вырождается в O(m), то же самое произойдет с хэш мапой, если количество элементов не превышает 64, то помещая во внешний цикл мы получим не O(n*m), а O(64*m), что соответствует просто O(m).
Ещё можно про lost update расскать.
А есть в голове счётчик расстройств при собеседовании?) Если Макс за собес расстроился более N раз, то кандидат не подходит.
Ахах, просто убил)))
Макс, ты не рассказал для чего вообще TreeSet нужен! Что у него есть методы first(), last(), lower(E e), higher(E e). Которых нет в других сетах.
Тут ещё важно добавить про уровни изоляции транзакций, что чем ниже уровень изоляции транзакции, тем быстрее они работают, потому что меньше механизмов блокировок задействовано. Если у вас высоконагруженое приложение, и в некоторых местах, если конечно такие есть, можно пожертвовать изоляцией в пользу быстродействия, то почему бы и нет?
прикольный дисклеймер, жаль что он появился ток после 22 февраля а не 9 лет назад))
Иногда необходимо время чтобы открыть глаза, увидеть правду и сказать о ней.
Но справедливости ради, 9 лет назад на территории Украины не было открытого нападения соседнего государства (исключение Крым)
@@Jetbulbпонял, война междоусобная, между людьми областей и силовиками государства за войну не считается, а ролик очень познавательный, спасибо
Кто-то использовал трисет в проекте?
Использовал
13:20 так и не назвал причину, почему для ТриСет нужно переопределить иквалз
Если кратко, TreeSet под капотом хранит TreeMap. Соответственно, equals+hashcode должны быть согласованы для работы с ключами (сортировка, поиск). Как это завещает TreeMap.
Самый верный вариант для изучения этой темы: - "просто открыть класс и пройтись строка за строкой." Тогда на долго отложится это знание и появится понимание. По крайней мере именно это мне помогло.
Топчик. спасибо.
Хотелось бы попробовать такое тестовое собеседование. Считаю себя мидлом, но, кажется, это не совсем так)
Детали интервью: что выбрать, как попасть и прочее ... по ссылке
iprody.com/interview
:)
Переменная которая отвечает за увеличения размера Map называется DEFAULT_LOAD_FACTOR, а не THRESHOLD
"@Transactional создает обертку с try catch " - возможно блок трай кетч там и присутствует, но суть не в этом. суть именно в создании транзакции на уровне бд.
Я бы в образовательных целях добавил к этому что обертка это прокси класс, что это паттерн, реализуемый при помощи аоп и он изящно разносит бизнес логику и рутинные операции а ля открытие/закрытие транзакции
Привет! У тебя есть видео про SDET? Сейчас прохожу bootcamp и голова плавится, представляю что с девелопарами происходит. Это видео реально интересно посмотреть.
Привет!
Такого видео пока нет. Признаюсь и не думали о таком )
Спасибо за фидбек
работаю долго на первой работе
скоро будет почти 15 лет...
получается больше как поддержка базы данных и данной системы
(отчеты всякие большую часть занимают)
не скажу что совсем ничего не интересовался
интересовался, читал книги по c++, java, ковырялся в разных проектах (unreal engine, прочие)
делал приложения на android где backend на php простенький писал
теперь думаю работу другую найти уже как java-разработчик
придется идти как начинающий, но даже тут зарплаты могут быть выше чем у меня сейчас
по сравнению с c++, в java порядок считай
до всяких обновлений в c++ там был ужас, что с stl, что с прочими стандартными библиотеками
понятно что с++ нужный язык, на нем саму jvm написали и прочее
но он обычно востребован в серьезных конторах, а их немного
уже тошнит ходить на работу и этим заниматься...
а найти новую еще придется пытаться искать
сейчас ковыряю в VueJs, Spring Boot
а как же Not_Supported, 7 уровень в пропогации транзакции?
хороший опыт, всем ребят советую сдать для начала OCP17 экзамен по java, а потом получать "коммерческий" опыт. Я на собственном примере понял , что Oracle экзамен это лучшая подготовка к собеседованию и даёт не поверхностное пониманиe того как работает java. Всем мира )
не уверен, но при простой коллизии нода вроде не перестраивается в дерево. Там есть лимит на количество элементов в бакете (вроде 8) и общее число бакетов (вроде 32). 2 этих условия с логическим и. Порог же вроде loadFactor?
Еще по тримапе интересный вопрос можно задать: как в тримапу положить объект, который не реализует comparable и мы не передаем компаратор? На как тогда будут сортироваться ключи?
Максим, а как можно к тебе попасть на собеседование (junior position)?
Привет )
Можешь написать сюда t.me/iPrody_Online
Здравствуйте, подскажите: я не знал, что тремпель - это вешалка, но пользовался им;
Вопрос: если я не знал термина полимлрфизм, но в работе использовал механизм так называемый … то это говорит, что спрашивать термин нет смысла? Спасибо
Привет )))
Вопрос очень неоднозначный и холиварный, но попробую ответь:
«Если человек успешно применят какой-либо прием и даже не подозревает об этом. То это круто! Для меня это сигнал, что человек думает и может сотворять.
Однако, есть и другая сторона медали. Сложно назвать человека инженером, если он применяет что-то фундаментальное из своей отрасли, но сам того не подозревая»
Это тонкая грань. Одно и второе имеет место быть и вовсе не может характеризовать человека как плохо сотрудника. Это вопрос конкретной позиции и требований выдвигаемых этой позицией.
@@Jetbulb Что можно порекомендовать отвечать, когда уже долго работаешь и теория выветрилась? Так не хочется повторно учить слова, а читать знакомое претит
@@for_find_me006 Как говорится: "Рыбак рыбака видит из далека". Так и тут. Опыт видно из далека. Человек с опытом уже говорит и обосновывает вещи иначе. Я к тому, что притворство очень легко изобличить. Если не знаешь, то это будет видно практически сразу. Дело же не только теории и терминологии
Щось не зрозумів про додавання елемента при колізії в HashMap. Хіба він не додається в кінець списку в бакеті?
Елементи в бакет додаются в початок списку.
Що саме незрозуміло?)
@@Jetbulb Якщо, є три value наприклад: object1, object2, object3. То при колізії їх ключів, порядок в бакеті буде object1 -> object2 -> object3. Так? Бо якщо додавати на початок списку, то виглядає так, наче порядок має бути такий object3 -> object2 -> object1
Як завжди цікаво і пізнавально)
про @Transactional:
а как же TransactionInterceptor, TransactionManager, EntityManager причем тут прокси и тд?
Разве не этого ждешь при вопросе, как работает?
Это всего лишь один из вопросов.
Не стоит из него делать "центрирование". Конечно же есть и другие вопросы и они тоже задаются.
@@Jetbulb я просто думал) нужно об этом рассказывать, когда задается такой вопрос)
При пессимистичной блокировке запрещены апдейты, а читать можно вполне
Я бы хотел попробовать себя на собеседовании и получить рекомендации, что нужно подтянуть и что вообще делать. Стоит ли мне пытаться искать работу или еще поучиться.
Тогда надо на собеседование записываться)
Мы как раз проводим мок-интервью.
Если интересно, детали можно посмотреть interview.jetbulb.com/
@@Jetbulb чет у вас страница с интервью упала((
@@oopsoops9040 спасибо) Сейчас проверим
@@Jetbulb не получается получить доступ к сайту всё равно)
@@oopsoops9040 Все работает, несколько раз проверяли.
Ссылка действующая)
Максим, добрый день! Может вопрос не сюда))) Но подскажите плиз, когда Вы планируете вести курс Java Pro в Hillel?
Мая, приветствую))
Точно буду занят текущей группой до НГ. А дальше еще не знаю.
Лучше это уточнять в учебном отделе. Они ведают планированием)
Спасибо за интерес. Балуете меня ☺️
Про хэшмап перепутал, назвал случай неправильно реализованноых иквалз хешкод коллизией, когда О(н), когда хешкод возвращает константу.
Очень странный собес на мидла. Обычно мало вопросов по джаве, но много по сопутствующим фреймворкам и технологиям. Около 30 собесов за полгода уже прошёл 🥴
У разных компаний разные собеседования. Есть кто даёт сразу задачи на алгоритмы и нужно писать код сразу и быстро. Кто-то спрашивает по брокеры сообщений (какие есть, основные отличия), про NoSQL, docker, helm, Kubernetes. Другие дают задачи на проектирования и т.д.
Посмотрел ужн кучу мок интервью, и думаю, что ответил бы на большинство вопросов верно. Но меня всегда удивляют такие вопросы на собеседованиях. Всегда живу с мыслью о том, что учить это надо только для того, чтобы пройти собеседование на случай, если будут попадаться неадекватные интервьюверы. В работе эти знания никогда не пригодятся или их польза стремится к нулю...
Привет, подскажи, что у тебя за монитор?
Прошу прощения. очень уж режет слух тест дрАйвен девелопмент. по аглицки - тест дрИвен девеломпент. Еще раз прошу прощения.
Если мы говорим об общем случае (в Java возможно сценарий не воспроизводится) для цикла в графе ожиданий (deadlock) достаточно одного потока:
Например:
mutex_lock(m);
mutex_lock(m);
Propagation.NOT_SUPPORTED забыт.