Is this new friend for performance aware java programmer?

Atomic values

More theory (from IBM):

Basically this whole thing is about avoiding syncronization and using volatile fields for doing it. Naturally assisted with our old-friend, ”Mr. Unsafe”.

Cool, well, I think so this feels cool. It’s however, upto performance analysis to tell if these Atomic -values give performance advantage over some old fashioned int field, with synchronized accessors of your own.

Thread safety
I love this comment from the article

”… (Note that simply synchronizing every method does not, in general, render a class thread-safe) … ”

And I can only truly agreet with the wisdom of that.

My lock, your lock, all locks of ours..

Yes, I also fall in love with Lock. Just check those performance comparison figures from IBM articles, and you will love it also.

However, one must remember that only The Profiler can tell if there is really need for optimization in code. So better to not rush into advanced lock concepts instead of synchronized.

But, Lock allows nicely implementing few other synchronization semantics in much more easier manner. Like the fact that lock acquiring and releasing are not required to be within single ”try {…} finally” -block, and also possibility to check if lock exists; instead of block thread due to synchronized. These features allow nicely to implement various background worker/refresh logics, which efficiently avoid freezing EDT in Swing. Cool, eh?

Primitive type collections
And while talking about performance. Can we ignore Trove? No, propably no.

The Trove collection classes.

/ java

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *

This site uses Akismet to reduce spam. Learn how your comment data is processed.