Check out this post and learn how to be more memory efficient when writing your Java code with the Atomic*FieldUpdater.
Let’s be friends:
Comment (0)
Join the DZone community and get the full member experience.
A lot of people talk/write about premature optimization when they need to write „advanced“ code and be a bit more memory efficient. But I am asking: Where does premature optimization start and where does it end? Is there any difference when you write an application or library?
Actually, I don’t know the answer; I just want to put together some facts in today’s blog and give a clue as to how to write a bit more memory efficient code. Let’s introduce a not-so-familiar class from the java.util.concurrent package and compare it to the well-known java.util.concurrent.atomic. AtomicInteger.
Let’s look at the Java object layout library (jol-core)to see what it looks like inside:
16 bytes (-XX:+UseCompressedOops) in total can be divided into several groups:
Our class AtomicCounter:
AtomicInteger:
AtomicUpdater:
Static variable (one-off cost)
It’s pretty obvious that if you use only one object (e.
