How many bytes of memory does a java.util.Date object use?

I need to store a large amount of dates (poten开发者_如何学编程tially large enough that the amount of heap space used is a concern so please, no lectures on premature optimization), and I'm wondering if it makes sense to use some sort of primitive representation instead of java.util.Date (or some other existing Date class). I know I could do some profiling to try it out, but does anyone know off-hand exactly how many bytes of memory a single Date object uses?

My gut reaction was that the memory overhead for Date would be very small. Examining the source code it seems that the class only contains one instance field (a long called milliseconds). Which means the size of a date object is the size of a long plus the size of an instance of Object -- that is, very small.

I then found this code that creates thousands of objects to determine the size of the object. It says that the size of java.util.Date is 32 bytes. Compare that with just storing a the date as a long (which is what it does internally) -- a long is 8 bytes, so you have to pay four fold for the convenience of having a date object.

However, the overhead of creating of objects isn't very high. So if you're really that worried about space then store the dates as longs and create a Date object as and when needed.

Use the primitive long ?

It is not an object, so less space, and dates can be expressed as a long value. Then convert back and forth between Date and long when you want to store the dates and use less memory.

using java's instrumentation framework, getObjectSize says it's 24B.

^{As answered here too:}

Easiest way to answer this question is to look at the source code of java.util.Date.

It has only 2 non-static fields (Java 1.7.0_55):

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

long has a memory size of 8 bytes and cdate is an object reference which has a size of 4 bytes. So a total of 12 bytes.

If cdate would be instantiated, it could require additional bytes in the memory, but if you look at the constructors too, sometimes it won't even be touched, and in others it will be null-ed at the end of the constructor, so the final result is also 12 bytes.

This is just for creating a Date. If you call methods on the Date (for example Date.toString()), that will create and store an object into the cdate field which will not be cleared. So if you call certain methods on the Date, its memory usage will increase.

Note: Object references might be 64 bit long on 64-bit JVMs in which case memory usage would be 16 bytes.

Note #2: Also note that this is just the memory usage of the Date object itself. Most likely you will store its reference somewhere, e.g. in an array or list or a field in some other class which will require additional 4 bytes (or maybe 8 bytes on 64 bit JVMs).

If it's literally date, rather than date & timestamp, you could even use an int:

20110113

I tried a manual calculation based on the rules here: http://www.javamex.com/tutorials/memory/object_memory_usage.shtml and checking the source code of the Date object in Java 7 the memory usage.

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

Maybe I'm missing something in the calculation or the tools that were used in other answers that gave a result of 32 were including the references to the dates themselves in the calculation?

java.util.Date object can be represented by a long value and a long value is 8 bytes -2^63 to (2^63)-1