Last Updated: February 25, 2016
· lfernandez93

Immutable vs Mutable JAVA

Hello everyone, i'm starting to studying the Immutable vs Mutable topic, and its really wonderful how the Immutable objects saves you from a lot of bugs your code could generate when it's in production lets define Mutable and Immutable first:

  • Mutable: an object is mutable when you can change its value and it actually creates a new reference in memory of this object for example:

    int a=0;

    What is happening here is that 'a' variable is being created in memory (with a new reference there) once and once again till it reachs the 9 value what is not good when you are developing apps where the perfomance is a main objetive you need to maintain, in contrast we have our saviors the immutable objects!.

  • Immutable: an object is immutable when you can not change its value once it's referenced because it only creates one reference in memory the only thing you could do is redeclaring the object that will turn in losing all the values it had. Some of the classes that are immutable in java are the Wrapper classes just like Integer,Float,Double,Character,Byte for example:

    Integer a=0;

    What is happening here is so much different what happened before with the mutable object, in this case the 'a' variable is being created one time in memory, and because the object is actually immutable it doens't create a new reference in memory, it updates the one already created another example of Immutable Objects would be this one:

    Integer a=0;
    Integer b=0;
    System.out.println(a); //it outputs 1

In this example the objects when you say that 'a=b' are referencing to the same space of memory,in this way, if you change b you will be referencing to the same position of a what will turn that a gets the same value of b , when we see this in the side of mutable object you are actually creating 2 different references in memory what will leave you change 1 value without changing the another or messing up with it.

I hope you like it, feel free to comment any suggest :)


3 Responses
Add your response


You talk about performance and you are comparing int and Integer which seems very odd (when chosing Integer over int). Moreover, using the Autoboxing is not the better thing you can do…

over 1 year ago ·

Good point opatry, i appreciate you point of view, and of course the auto boxing is not the best way but i think is a fancy way to understand mutable and immutable classes, Greetings!

over 1 year ago ·

Well a primitive isn't an object, that's when mutability matters. Look up how HashMaps and Lists work, those are the objects that are very concerned with mutating state.

For example if you have a method that takes a primitive:

public void foo(int i)

the primitives will be as you say "mutated". But thats no mutation, it simply means that into the function these variables's values are passed (ie, they are copied). It really doesn't matter because these copies go away the moment the function ends, it isnt something that needs to be garbage collected. In fact a variable like this will most likely end up in the CPU's cache, and not in ram.

It isnt strictly a performance thing, its how the data structure behaves. Mutability is a huge topic when talking about sharing state in a multithreaded application.

over 1 year ago ·