This is my first seriously technical blog. So, there is always a good chance that I might falter a bit too often.

Let’s try to understand about usage of Atomic Integer concept during Synchronization in this blog.

I have been working in a firm that does Pacs Data Migration (and related activities) day in and out. We have numerous applications that have been basically written in JAVA (besides a few PERL scripts) that continually process data. Since we process huge number of records every day, it’s always nice to speed up the applications. This means faster migration, faster closure of the project and hence faster bucks!

I was recently working on one of our applications in order to optimize its behavior. We usually run it as a Multi-threaded process. As we are all aware , synchronization of shared resources is a huge bottle neck in a multi-threaded process. There was one mysql query that was eating a lot of our time.

This is what we used to do in a Synchronized block

1) Select one record at a time (naturally the query would be something like, “select abc , xyz from table where somecondtion limit 1)

and

2) Mark it as selected by updating it to “INPROGRESS”, so that the same record is not picked by other thread(s).

This takes a lot of time and is a huge bottleneck in our application. So,we had to somehow minimize the amount of time spent in the synchronized block. After wandering around with various solutions with decent yet not-very-great improvements, I finally hit upon something called as Atomic Integer which I hadn’t earlier heard of (neither did anyone in the team!).

http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/atomic/AtomicInteger.html

Lemme explain Atomic Integer

“Atomicity” means that an operation must be executed as a single unit, in order to avoid inconsistencies.

An Atomic Integer ensures that your value is changed ‘atomically’ which means that you no longer need to write those synchronized blocks in your code…phew…that’s some relief!

so .. how did this help me?

Well… coming back to the application…

I changed the query :

select abc , xyz from table where some condition limit 1

to

select abc , xyz , def from table where some condition limit myAtomicIntegerCounter , 1

where each thread increments the myAtomicInteger before it executes the above query.

The API provides the methods

                     incrementAndGet() and getAndDecrement()

for this purpose (and I used the former) .

Using these , one can increment the counter atomically(in loose words , one at a time in a synchronized fashion).

So my queries will now be like :

selct abc , xyz from table where somecondtion limit 0,1;

selct abc , xyz from table where somecondtion limit 1,1;

selct abc , xyz from table where somecondtion limit 2,1;

. . .

. . .

. . .

selct abc , xyz from table limit n,1;

Note : The API has a few more handy methods which one must check out.

Of course , the mysql query of the form limit x,y has its own overheads. Nonetheless, its far more efficient that doing the whole select-update duo in a synchronized block.

Moreover , AtomicInteger employs native calls for synchronization which on any day are much more efficient than our synchronized blocks.

It is not done yet. Plan to dive deeper into java.util.concurrent.atomic.AtomicInteger package and when I do dig some more gold, shall let you know!