This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hello i have problem when i read object from file that generated from this code :
this is how i read the object, i'm using thread because i want to keep up to date with the file, so it will keep reading in interval... the file that i read is about 15mb... but i dunt know how when i read object it will consume about 100-150mb memory in heap. i'm using jprofiler to measure.
this is code how i read this file :
This is main program :
does anyone know, why my program consumes about 100-150mb when deserialize object from 15mb file.
Well, you've got about 45 MB worth of objects there (1 million times about 20 bytes for an Integer and about 24 for a Map.Entry), plus there's the Hashtable that the ObjectXStreams will use to keep track of whether or not they're already serialized an object, which will consume another ~24M or so; so it looks like either the read or write program will not quite fit into the default 64M heap. I'd think that either one would run within a 100M or so, and not need any more than that.That's the Java heap itself, mind you; the JVM's native code and such consume additional space outside of the heap.
There's no official documentation for that, and it of course varies across JVMs. But the rule I always use, and it works well for me, is to allow 16 bytes for an object, plus the size of its member variables. An Integer has one "int" member, so it's 20 bytes. A Map.Entry has at least two reference variable entries to point to the key and value, so I said 24 bytes. But now that I think of it, it probably has at least one more member so that entries can be in a linked list...
OK, I went and looked at the JDK source code. A Hashtable.Entry has four members: an int to hold a hash value, and three reference variables, so I would count that as 16 + 4 + 12 = 32 bytes; my earlier estimate was a little low, then.