Видимо у вас схема взаимодействия не выстраивается в голове.
Вы клиентом (браузером) делаете запрос sub1.test.ru dns отдал вам ип хоста на котором расположен этот домен. Помимо sub1.test.ru на этом хосте может располагаться великое множество сайтов, aaa.ru bbb.ru и фронтэнд этого сайта при получении запроса от Вашего клиента уже решает что именно вам отдать (какую директорию), Вы же спрашивали sub1.test.ru то он Вам и отдаст, точнее клиенту.
решает что именно вам отдатьну впрочем, уже ответили, что по записи в хосте в заголовке запроса.
откуда может взяться так уж много новых полей взамен старых?
Зачастую это никак не сказывается на работоспособности уже отлаженных продуктов, но иногда требуются очень масштабные вмешательства, о которых лучше узнать заранее — и подготовиться к ним должным образом.
Можно предположить, что несмотря на изменение физического расположения объекта в памяти, некий internal address остаётся у него неизменным.
Автор текста имел ввиду, что даже если какая-то JVM (Zing например) генерирует хэшкод на основе адреса, то только при первом вызове, а потом возвращает его уже из заголовков.
3. Учитывается заполнение всех бакетов. В вашем случае, когда элементы возвращают один и тот же хэш, а значит скапливаются в одном бакете, будет учитываться другой параметр - TREEIFY_THRESHOLD. По умолчанию он равен 8 и после накопления в бакете стольки элементов, он будет преобразован из списка в дерево.
некий internal address остаётся у него неизменным. Возможно, рассуждений в таком духе от тебя и ожидали.
То, что ты спрашиваешь, это не изучение джавы, это изучение незначительных(для прикладного разработчика) деталей реализации JVM.
Для того, чтобы написать коммент выше, мне пришлось взять ноут, залезть-таки в исходники и скопипастить их тебе сюда. Причём это исходники конкретной мапы, в других реализациях может быть вообще другой код. Важен принцип, и ты его можешь сам посмотреть в исходниках, это весьма полезно. Читать документацию, не ожидая, что её разжуют, тоже полезно.