Java. Класс Object. Разбор вопросов на собеседование.
HTML-код
- Опубликовано: 28 авг 2020
- В данном видео я разбираю вопросы по классу Object на собеседование для начинающих Java разработчиков. Это вопросы из моего личного списка, те что я сам время от времени задаю.
Привожу их тут, чтобы помочь в подготовке, так как практика показывает, что часто этим вопросам уделяется недостаточно внимания:
1.Все классы в Java наследуются от Object, как вы думаете, почему так сделано?
2.Можно ли создать экземпляр класса Object?
3.Зачем кому-то может понадобится создавать экземпляр класса Object?
4.Опишите методы класса Object.
5.Особенности методов wait, notify, notifyAll
6.Что такое хэш-код. Что за значение позвращает метод hashCode класса Object?
7.Как связаны между собой методы equals и hashCode? Что будет, если переопределить equals не переопределяя hashCode? Что будет если у объекта-ключа HashMap изменится хэш-код? Какие могут возникнуть проблемы?
8.Метод finalize, для чего нужен?
Так же рекомендую посмотреть видео, более подробно раскрывающие вопросы:
1) Подробный разбор методов equals() и hashCode():
• Java. Методы equals и ...
2) Методы wait() и notify():
• Java. Многопоточность....
Хорошая статья о реализации hashCode() класса Object для желающих погрузиться в вопрос:
habr.com/ru/company/mailru/bl...
Поддержать канал💰:
yoomoney.ru/to/410018856244871
Наша группа в Telegram:
t.me/ArhiTutorials
#ArhiTutorialsJava #ityoutubersru
Спасибо за видео! Было очень интересно послушать какие вопросы могут задаваться джуну. Ну, и ответы, конечно, тоже. Я только обучаюсь, и недавно разбирался с HashCode и Equals. Позвольте для новичков, которые будут смотреть комменты, добавить немного инфы:
Может возникнуть вопрос: зачем нужно сравнение по HashCode , если он не дает чёткого ответа равны ли объекты или нет? почему не использовать только equals?
Дело в скорости реализации методов. Так как сравнение HashCode это сравнение двух цельных чисел, то это очень быстрая операция. Сравнение по equals занимает больше времени. Поэтому мы сначала сравниваем по хеш-коду: хэш разный? значит объекты точно разные - сравнение можно закончить. Хеш - одинаковый? Тогда нужно сравнить объекты еще через equals.
Хорошее, доходчивое объяснение. Спасибо!
Сергей, спасибо, всё понятно и доходчиво 👍
Как-же круто вы обьясняете, нет слов!).
Сергей, спасибо !!! вы очень помогли, всё по полочкам... !!!
Спасибо, приятно слушать
Спасибо! Хорошо объясняете.
Спасибо, очень полезно!
очень классное видео.спасибо! спасибо! можно видео по коллекциям? как они работают?как устроены? что на собеседовании по ним спрашивают?
Спасибо за хорошие видео))
Очень крутое интервью. Просим больше! И про Андроид, в том числе.
классное объяснение, спасибо
жду продолжения)
Большое спасибо
16:45 супер объяснили! спасибо
Thanks a million!!!👍👍👍
Класс!
Спасибо!!!
Больше java)) разбор вопросов для собеседований) плз.
До просмотра я думал что hashCode() класса object возвращает именно адрес в памяти. После объективного опровержения этого факта (причем с визуализацией) я понял что можно довольно долго обладать ошибочными знаниями и даже не подозревать об этом. Теперь, одной тайной для меня стало больше.
Однако кроме всего прочего хочу отметить что слухи и домыслы (а так же предрассудки) не берутся на пустом месте и часто имеют под собой порой хоть и не логичное но объяснение, поэтому осмелюсь выдвинуть свою гипотезу происхождения этого числа. Я думаю что при формировании hash code у объекта класса object встроенный алгоритм МОЖЕТ использовать ПЕРВОНАЧАЛЬНЫЙ адрес в памяти этого объекта и сохраняет его где-то в метаинформации самого инстанса класса object. Могу сразу же привести аргументы против моей теории. Так как первые GC (например Serial) создавали свои объекты на относительно ограниченном участке в памяти (eden space чего не скажешь о G1 например) говорить что числовое пространство велико не представляется возможным.
Я всего лишь учусь и тем более не являюсь ни Middle ни Senior java разработчиком и готов "словить на себя" все помидоры которые полетят в мою сторону, но на сколько под собой имеет смысл такое восприятие картины формирования hashCode у объекта класса Object? Сильно ли дико будет выдвинуть такое "свое" мировозрение например на собеседовании на первую работу какому-нибудь из собеседующих или жди беды?
Я бы сделал ещё одну проверку на null над синхронайзд
if (database == null)
Правильно. Без этой проверки ненужный заход в synchronized блок происходит каждый раз, когда надо получить instance, что очень нехорошо сказывается на производительности.
Тогда не будет hb между созданием объекта и чтением ссылки на него (если, конечно, нет volatile поля или других действий с hb ребром). Если объект не иммутабельный (без final полей) можно прочитать его в не консистентном состоянии.
6:43 Работать будет корректно. Но при каждом получении инстанса захватывать блокировку дорого. Лучше свалить эту задачу на класслоудер (статический класс holder завести) или вообще инстанцировать один раз самому и не маяться фигнёй с защитой от того чтобы нельзя было создавать второй инстанс. Чтобы не просовывать ссылочку везде руками можно об этом попросить Dagger или какой-нибудь другой DI.
Идеальное видео. Спасибо огромное. Хотелось бы видео посвящённое анализу ошибок.
Из-за чего у приложения и сервера могут быть ошибки, сбои в работе? Каковы главные причины этих ошибок, сбоев? Что нужно для поиска причины и устранения ошибок и сбоев?
Подскажите ресурс где с примерами объясгяют Concurrency спасибо!
На 11:52 опечатка: должно быть min int -2….48, а max int 2….47
А где сам этот код пишется? Что за программа нужна?
Пример использования Object: logger.error("one two three: {}", new Object[] {"something went wrong"});
нвсчет sinhronized и создание базы данных: я бы перед блоком синхронайзед добавил бы if (database != null) return database; ибо синхронайзед дорогая вещь и ни к чему заходить в этот блок, если база уже есть. В самом блоке нужно ЕЩЕ РАЗ проверить.
Без volatile на database этого недостаточно
enum NaturalOrderComparator implements Comparator {
INSTANCE;
}
Синглтон (Сериализация, Потокобезопасность)
Хитро!
6:42 в таком случае сам метод стоит сделать synchronized, переменную инстанса volatile. Это моё не профессиональное мнение.
Проблема в том, что syncronized нужен только один раз для инициализации синглтона. Все последующие обращения лишь читают database, а синхронизация просто тратит ресурсы впустую. Нужно написать код так, чтоб если database != null, то синхронизацию не делать.
Да и вообще, так ли нужен в данном случае синглтон, который будет инициализироваться из разных потоков? Почему бы не вынести инициализацию в отдельный метод и вызывать его в методе onCreate() класса Application.
В Android во многих случаях можно гарантировать, что инициализация будет выполнена в UI потоке, и синхронизация тогда не нужна. Правда тогда это уже не будет такой красивый паттерн, как сейчас, зато дешево надежно и практично.
Получается HashSet это вроде двумерный массив?
Ага, а список - это частный случай дерева, которое не разветвляется)
а что за число 31 в функции хешкод?
Нужно простое число, чтоб получилась хорошая хэш-функция.
Это связано со свойствами простых чисел.
Лике подписон
Подожите, а что значит, что если хэшкоды не равны мы ничего не можем сказать об этих объектах. Согласно контракту если хэшкоды не равны, то объекты и не равны, функция хэшкода как раз и нужна для простого сравнения объетов, тк сравнение по хэшкоду куда "дешевле" чем сравнение по иквалсу.
В конце исправился, а в начале ошибка
Это на Джуна? вы че угараете? что за вопросы!
А что тут такого? На джуниора как раз базу спрашивают, а что еще спрашивать? На синьора вопросы другие, например: как бы вы организовали сервис синхронизации событий с google календарем, или, как бы вы реализовали планировщик смс рассылки. Это я так, примерно написал. У мидлов и синьоров уже есть опыт работы, и вместо теории лучше просто обсудить прошлые проекты и принятые на них технические решения.
Неадекватное интервью
12:07 Ну почему же совсем ничего, это значит что есть шанс, что и объекты равны или это вообще тот же самый объект)