Would it make sense to use AtomicInteger in some arbitrary Java code instead of Integer? Even in a single-threaded context, where thread safety is not an issue?
Would that help with performance in any way?
Asked
Active
Viewed 185 times
-4
GhostCat
- 137,827
- 25
- 176
- 248
Ashikur2146
- 21
- 1
-
1Why do you think you won't be able to do that? – Mark Rotteveel Jul 21 '17 at 11:10
-
Yes, it can. There is no reason for it to not work. – Philipp Jul 21 '17 at 11:17
-
Try it, TBH. Or if you're asking about performances, clarity or such, precise it in your question. – Turtle Jul 21 '17 at 11:21
-
Any feedback on my answer, like - is something missing in order to get it accept-worthy? – GhostCat Jul 24 '17 at 11:19
1 Answers
2
No: Integer is a somewhat special class. For example the compiler knows how to auto-box int to Integer and Integer to int.
Yes: both classes represent whole numbers. They both extend the Number class. So sure, you can use AtomicInteger as replacement for Integer.
But: keep in mind that AtomicInteger simply has special properties that normal Integers do not have. These special abilities do not come for free. So there is a potential very real performance penalty for blindly doing it.
And of course: you don't write source code because you can. You strive to write exactly that source code that is required to solve a certain problem. Meaning: you use int primitive types when you need them; you use Integer objects when you have to, you use AtomicInteger when the problem statement requires to do so.
In other words: when you go for duck hunting, you pick a shotgun. Of course, you could also use an assault rifle (both are guns in the end). It is just that different tools have different usage scenarios, and you pick that tool that best fits the job.
Beyond that, you get performance wrong. Completely wrong. Your comment implies that you think: "AtomicIntegers are mutable; Integers are not" ... so I guess your conclusion is: their performance is better.
What you are forgetting: they are not only mutable, they also guarantee atomic behavior. And guess how that is achieved: A) by using com.misc.Unsafe and B) private volatile int value;
Meaning: AtomicInteger has a volatile field. Each and any update is written to main memory. Do you have any idea how long writing to memory takes?!
Probably not - then let's see:
L1 cache reference 1 second
Branch mispredict 10 seconds
L2 cache reference 14 seconds
Main memory reference 3.3 minutes
( source )
I only used the last column - which scales to human understandable measures.
Meaning: when going to the L1 cache would cost 1 second - the table tells you that turning to memory costs 3 minutes.
So your idea of improving performance by using that "mutable" class gives 180 times performance penalty.
Long story short:
- premature optimization is the root of all evil
- when you think about performance - sorry, you have to understand the full stack, top to bottom
Long story short: one doesn't worry about performance until one has real issues (like testers/customers complaining at a function takes to much time). Then you start to investigate. You do profiling to understand what exactly causes the performance problem. Then you fix that. Of course, you avoid making outright stupid mistakes. In your case: when your program has to do so intensive computing on whole numbers that you worry about performance, the answer is simple: then you would use primitive type int values; and completely avoid reference type Integer objects in the first place.
-
AtomicInteger is mutable, and Integer is immutable. Shouldn't mutable objects perform faster!? – Ashikur2146 Jul 21 '17 at 12:49