Java. Класс Object. Разбор вопросов на собеседование.

[@mikhailgureev218]

великолепно проводёл время на этом канале

[@NikolaiStiazhkin]

Сергей, спасибо !!! вы очень помогли, всё по полочкам... !!!

[@СергейСтрельченко-м2ф]

Как-же круто вы обьясняете, нет слов!).

[@veygard]

Спасибо за видео! Было очень интересно послушать какие вопросы могут задаваться джуну. Ну, и ответы, конечно, тоже. Я только обучаюсь, и недавно разбирался с HashCode и Equals. Позвольте для новичков, которые будут смотреть комменты, добавить немного инфы: Может возникнуть вопрос: зачем нужно сравнение по HashCode , если он не дает чёткого ответа равны ли объекты или нет? почему не использовать только equals? Дело в скорости реализации методов. Так как сравнение HashCode это сравнение двух цельных чисел, то это очень быстрая операция. Сравнение по equals занимает больше времени. Поэтому мы сначала сравниваем по хеш-коду: хэш разный? значит объекты точно разные - сравнение можно закончить. Хеш - одинаковый? Тогда нужно сравнить объекты еще через equals.

[@winter-lb7id]

11:56 - очень важное понимание, недавно в разговоре сам к такому же выводу пришел

[@НикитаСологуб-щ3ц]

До просмотра я думал что hashCode() класса object возвращает именно адрес в памяти. После объективного опровержения этого факта (причем с визуализацией) я понял что можно довольно долго обладать ошибочными знаниями и даже не подозревать об этом. Теперь, одной тайной для меня стало больше. Однако кроме всего прочего хочу отметить что слухи и домыслы (а так же предрассудки) не берутся на пустом месте и часто имеют под собой порой хоть и не логичное но объяснение, поэтому осмелюсь выдвинуть свою гипотезу происхождения этого числа. Я думаю что при формировании hash code у объекта класса object встроенный алгоритм МОЖЕТ использовать ПЕРВОНАЧАЛЬНЫЙ адрес в памяти этого объекта и сохраняет его где-то в метаинформации самого инстанса класса object. Могу сразу же привести аргументы против моей теории. Так как первые GC (например Serial) создавали свои объекты на относительно ограниченном участке в памяти (eden space чего не скажешь о G1 например) говорить что числовое пространство велико не представляется возможным. Я всего лишь учусь и тем более не являюсь ни Middle ни Senior java разработчиком и готов "словить на себя" все помидоры которые полетят в мою сторону, но на сколько под собой имеет смысл такое восприятие картины формирования hashCode у объекта класса Object? Сильно ли дико будет выдвинуть такое "свое" мировозрение например на собеседовании на первую работу какому-нибудь из собеседующих или жди беды?

[@TheDergraue]

Сергей, спасибо, всё понятно и доходчиво 👍

[@СэмФишер-х4д]

очень классное видео.спасибо! спасибо! можно видео по коллекциям? как они работают?как устроены? что на собеседовании по ним спрашивают?

[@smthsmth111]

Хорошее, доходчивое объяснение. Спасибо!

[@djadjaandrey]

Thanks a million!!!👍👍👍

[@МихаилАлександрович-ж2о]

Спасибо, приятно слушать

[@avpmk]

6:43 Работать будет корректно. Но при каждом получении инстанса захватывать блокировку дорого. Лучше свалить эту задачу на класслоудер (статический класс holder завести) или вообще инстанцировать один раз самому и не маяться фигнёй с защитой от того чтобы нельзя было создавать второй инстанс. Чтобы не просовывать ссылочку везде руками можно об этом попросить Dagger или какой-нибудь другой DI.

[@Андрей-Зубков]

Я бы сделал ещё одну проверку на null над синхронайзд if (database == null)

[@arhitutorials]

Правильно. Без этой проверки ненужный заход в synchronized блок происходит каждый раз, когда надо получить instance, что очень нехорошо сказывается на производительности.

[@avpmk]

Тогда не будет hb между созданием объекта и чтением ссылки на него (если, конечно, нет volatile поля или других действий с hb ребром). Если объект не иммутабельный (без final полей) можно прочитать его в не консистентном состоянии.

[@maywr3893]

классное объяснение, спасибо

[@РоманДеревяго]

16:45 супер объяснили! спасибо

[@Libra7by]

Очень крутое интервью. Просим больше! И про Андроид, в том числе.

[@Van8983]

Больше java)) разбор вопросов для собеседований) плз.

[@zvuk3316]

Спасибо! Хорошо объясняете.

[@vyacheslavlevinsky7601]

Большое спасибо

[@_._Nazar_._]

enum NaturalOrderComparator implements Comparator { INSTANCE; } Синглтон (Сериализация, Потокобезопасность)

[@antonstezhkin5991]

Хитро!

[@aleksanderpeshkin2266]

Серый привет 👋 Подскажи, а как ты издал все это в начале пути когда был джуном ?? Наследование где использовал при обучении ?? В книгах сухая информация ℹ️

[@arhitutorials]

@@aleksanderpeshkin2266 привет! Сам пробовал все, смотрел как другие пишут. Когда начинал, написал много такого кода, что страшно вспомнить)

[@СашаСтрельцов-в4с]

жду продолжения)

[@Dennis84918]

нвсчет sinhronized и создание базы данных: я бы перед блоком синхронайзед добавил бы if (database != null) return database; ибо синхронайзед дорогая вещь и ни к чему заходить в этот блок, если база уже есть. В самом блоке нужно ЕЩЕ РАЗ проверить.

[@IrkDrago]

Без volatile на database этого недостаточно

[@sergeyka347]

Пример использования Object: logger.error("one two three: {}", new Object[] {"something went wrong"});

[@АндрейМ-щ6и]

Спасибо за хорошие видео))

[@ryazhartur]

На 11:52 опечатка: должно быть min int -2….48, а max int 2….47

[@KnockNeo8701]

Класс!

[@anjelomanoranjan]

Идеальное видео. Спасибо огромное. Хотелось бы видео посвящённое анализу ошибок. Из-за чего у приложения и сервера могут быть ошибки, сбои в работе? Каковы главные причины этих ошибок, сбоев? Что нужно для поиска причины и устранения ошибок и сбоев?

[@caffeinejavacode1475]

Подскажите ресурс где с примерами объясгяют Concurrency спасибо!

[@MrTheMaks]

6:42 в таком случае сам метод стоит сделать synchronized, переменную инстанса volatile. Это моё не профессиональное мнение.

[@arhitutorials]

Проблема в том, что syncronized нужен только один раз для инициализации синглтона. Все последующие обращения лишь читают database, а синхронизация просто тратит ресурсы впустую. Нужно написать код так, чтоб если database != null, то синхронизацию не делать. Да и вообще, так ли нужен в данном случае синглтон, который будет инициализироваться из разных потоков? Почему бы не вынести инициализацию в отдельный метод и вызывать его в методе onCreate() класса Application. В Android во многих случаях можно гарантировать, что инициализация будет выполнена в UI потоке, и синхронизация тогда не нужна. Правда тогда это уже не будет такой красивый паттерн, как сейчас, зато дешево надежно и практично.

[@user-upKo-s-tik]

А где сам этот код пишется? Что за программа нужна?

[@viktor.florinskiy]

а что за число 31 в функции хешкод?

[@arhitutorials]

Нужно простое число, чтоб получилась хорошая хэш-функция. Это связано со свойствами простых чисел.

[@sfiirwuejnn]

Получается HashSet это вроде двумерный массив?

[@arhitutorials]

Ага, а список - это частный случай дерева, которое не разветвляется)

[@Qnoize]

Подожите, а что значит, что если хэшкоды не равны мы ничего не можем сказать об этих объектах. Согласно контракту если хэшкоды не равны, то объекты и не равны, функция хэшкода как раз и нужна для простого сравнения объетов, тк сравнение по хэшкоду куда "дешевле" чем сравнение по иквалсу. В конце исправился, а в начале ошибка

[@nikkie_cold]

Лике подписон

[@UnitXXVII]

Это на Джуна? вы че угараете? что за вопросы!

[@arhitutorials]

А что тут такого? На джуниора как раз базу спрашивают, а что еще спрашивать? На синьора вопросы другие, например: как бы вы организовали сервис синхронизации событий с google календарем, или, как бы вы реализовали планировщик смс рассылки. Это я так, примерно написал. У мидлов и синьоров уже есть опыт работы, и вместо теории лучше просто обсудить прошлые проекты и принятые на них технические решения.

[@CBET0MuP]

Неадекватное интервью

[@avpmk]

12:07 Ну почему же совсем ничего, это значит что есть шанс, что и объекты равны или это вообще тот же самый объект)

[@Andrzej3935]

Спасибо, очень полезно!

[@svalyavasvalyava9867]

Спасибо!!!