Сколько байтов памяти использует объект java.util.Date? - PullRequest
16 голосов
/ 13 января 2011

Мне нужно хранить большое количество дат (потенциально достаточно больших, чтобы объем используемого пространства кучи был проблемой, поэтому, пожалуйста, не читайте лекций по преждевременной оптимизации), и мне интересно, имеет ли смысл использовать какой-то вид примитивное представление вместо java.util.Date (или некоторого другого существующего класса Date). Я знаю, что мог бы выполнить какое-то профилирование, чтобы опробовать его, но кто-нибудь точно знает, сколько байтов памяти использует один объект Date?

Ответы [ 7 ]

15 голосов
/ 13 января 2011

Моя внутренняя реакция заключалась в том, что объем памяти для Date будет очень маленьким.Изучая исходный код, кажется, что класс содержит только одно поле экземпляра (долгое время называется миллисекундами).Это означает, что размер объекта даты равен размеру long плюс размер экземпляра Object, то есть очень мал.

Затем я нашел этот код , который создает тысячиобъектов для определения размера объекта.Это говорит о том, что размер java.util.Date составляет 32 байта.Сравните это с простым хранением даты как long (что она и делает внутри) - long составляет 8 байт, поэтому вам нужно заплатить в четыре раза за удобство наличия объекта date.

Однаконакладные расходы на создание объектов не очень высоки.Так что если вы действительно беспокоитесь о пространстве, сохраните даты как длинные и создайте объект Date по мере необходимости.

9 голосов
/ 13 января 2011

Использовать примитив долго?

Это не объект, поэтому меньше места, а даты можно выразить как длинное значение.Затем выполните преобразование даты и времени между датой и продолжительностью, если вы хотите сохранить даты и использовать меньше памяти.

3 голосов
/ 05 ноября 2011

с использованием инструментария java framework, getObjectSize говорит, что это 24B.

1 голос
/ 01 сентября 2014

В ответ здесь тоже:

Самый простой способ ответить на этот вопрос - взглянуть на исходный код java.util.Date.

Имеет только 2 нестатических поля (Java 1.7.0_55):

private transient long fastTime;
private transient BaseCalendar.Date cdate;

long имеет объем памяти 8 байтов, а cdate является ссылкой на объект, который имеет размер 4 байта. Таким образом, всего 12 байтов .

Если будет создан экземпляр cdate, это может потребовать дополнительных байтов в памяти, но если вы посмотрите и на конструкторы, иногда это даже не будет затронуто, а в других это будет null конец конструктора, поэтому конечный результат также равен 12 байтов .

Это просто для создания Date. Если вы вызываете методы для Date (например, Date.toString()), то создаст и сохранит объект в поле cdate, которое не будет очищено. Поэтому, если вы вызовете определенные методы для Date, использование памяти увеличится.

Примечание: Ссылки на объекты могут иметь длину 64 бита в 64-битных JVM, в этом случае использование памяти будет составлять 16 байтов.

Примечание # 2: Также обратите внимание, что это только использование памяти самого объекта Date. Скорее всего, вы будете хранить его ссылку где-нибудь, например. в массиве или списке или поле в каком-либо другом классе, для которого потребуются дополнительные 4 байта (или, возможно, 8 байтов в 64-битных JVM).

1 голос
/ 13 января 2011

Если это буквально date, а не date & timestamp, вы можете даже использовать int:

20110113

0 голосов
/ 22 августа 2014

Я попробовал ручной расчет, основанный на правилах здесь: http://www.javamex.com/tutorials/memory/object_memory_usage.shtml и проверяя исходный код объекта Date в Java 7 на использование памяти.

Object overhead: 8 bytes => 8 bytes
+ 1 long fastTime: 8 bytes => 16 bytes
+ 1 reference cdate: 4 bytes => 20 bytes
Rounded up to nearest multiple of 8 => 24 bytes

Может быть, мне чего-то не хватает в расчете, или инструменты, которые использовались в других ответах, которые дали результат 32, включали ссылки на сами даты в расчете?

0 голосов
/ 13 января 2011

java.util.Date объект может быть представлен длинным значением, а длинное значение составляет 8 байтов от -2 ^ 63 до (2 ^ 63) -1

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...