Как программист, я думаю, что они выглядят как "java.lang.Object по адресу 1a234552" или аналогичны для чего-то вроде s
in
Object s = "hello";
Это правильно? Поэтому все ссылки фиксированного размера?
Как программист, я думаю, что они выглядят как "java.lang.Object по адресу 1a234552" или аналогичны для чего-то вроде s
in
Object s = "hello";
Это правильно? Поэтому все ссылки фиксированного размера?
В то время как на многих виртуальных машинах размер ссылки - это собственный размер указателя (т.е. 32 бита для 32-разрядной JVM и 64 бит для 64-разрядной JVM), это не гарантируется - и в частности HotSpot либо делает сейчас, либо скоро будет поддерживать "Compressed Oops" , которые являются 32-разрядными ссылками в 64-битной JVM. (Это не означает, что каждая ссылка сжимается - прочитайте связанную статью для получения дополнительной информации, и есть много сообщений в блоге об этом тоже.)
В ответ на другой комментарий обратите внимание, что сама ссылка обычно является способом обращения к самому объекту. Является ли это прямой указатель памяти или нет, его целью является получение данных для объекта. Это в основном все, что действительно имеет значение. Если есть некоторые "запасные" биты (например, это 64-битная ссылка, и вам не нужна вся эта ширина только для представления местоположения объекта), то виртуальная машина может использовать эти данные для другой информации, такой как ее тип, что может позволить некоторые оптимизации. (См. Комментарий Tom для более подробной информации.)
Сам объект содержит информацию о типе (возможно, в виде ссылки на экземпляр Class
или что-то подобное - я не знаю достаточно подробно), а также другие необходимые "вещи" в заголовке, прежде чем вы перейдете к пользовательским данным для объекта.
Это не часть JLS или JVM Spec, но на практике это будет адрес: 32-разрядный бит на 32-битном процессоре, 64 на 64.
pqism: Хорошо, да, потому что после компиляции мы больше не заботимся о объявленном типе?
Мы заботимся. Вот почему объекты класса есть. Фактически, из других ответов вы можете видеть, что мы заботимся о типах во время выполнения, чтобы оптимизировать способ работы с ними, введя часть информации типа в ссылку.
Размер ссылки на объект зависит от архитектуры JVM и машины. Как правило, на 32-битной машине это 32 бита, а на 64-битной машине - 64 бита. Тем не менее, я думаю, что OpenJDK 7 JVM будет поддерживать "сжатые указатели", которые сэкономит место на 64-битных машинах.
Информация о типе объекта хранится в самом объекте; то есть, если вы будете следовать за 32-битным или 64-битным указателем (или, что более вероятно, дескриптором) для объекта, вы найдете другой указатель на экземпляр Class
, который описывает этот тип, а также поля данных объект.
Большинство людей склонны видеть ссылку на объект как указатель на языке C-language-like-memory. Хотя это не является технически корректным, большинство реализаций реализуют его как указатель. Например, в случае указателей сжатых объектов JVM хранит только биты с 3 по 34 64-разрядного указателя на 64-битной платформе. Другие реализации могут также использовать другую схему: ссылка может быть индексом в массив указателей, содержащий все объекты.