In general, using wrapper objects is less efficient for performance and memory use than using primitive types directly.
A wrapper object, for example an Integer, is just a small object that contains an int value. Primitive variables can be used in calculations directly, but when the primitive value is wrapped in an object, Java only has indirect access to the value: each time you use it in a calculation, the JVM has to get the value from the object.
Since autoboxing was added in Java 5, this overhead is not so clear, because it's not explicitly visible in the code what happens exactly. Let's look at a the following code:
What really happens here, with the help of autoboxing and -unboxing, is this:
You see that there are a lot of method calls there, which you would not have when you would be working directly with primitive int values. All those method calls make calculations with Integer wrapper objects a lot more work for the JVM than with primitive int values.
I've once tried out to find out how large a Double object was compared to a double primitive variable. It turned out that a Double uses 24 bytes on my JVM, while a double uses only 8 bytes. So if I'd want to store millions of double-precision floating-point variables in memory, using Double would make my program use three times as much memory as using double primitives.
Shanky Sohar wrote:If you are using wrapper classes in case of primitive types most of time then it may be possible that you will run out of memory.
But you can run out of memory as well when using primitive values. It's not as if it is impossible to run out of memory when you use primitives.