Java 8 Longadders: The right way to manage concurrency counters

Transferred from: http://www.importnew.com/11345.html

I just like the fresh stuff, and Java 8 has a lot of new things. This time I want to discuss one of my favorites: the Concurrency adder. This is a new collection of classes that they use to manage the counters that are read and written by multithreading . This new API, while significantly improving performance , still retains its simple and straightforward features.

After the advent of multi-core architectures, people solved concurrency counters, so let's see what the Java options for resolving concurrency counters are now, and compare their performance with the new API.

Dirty Counter – this method means that a regular object or static property is being read and written by multithreading. Unfortunately, because of two reasons this is not working. One reason is that in Java A + = B operation is not atomic. If you open the output bytecode, you will see at least four instructions-the first one to load the attribute values from the heap to the line stacks, the second to load the delta, the third to add them, and the fourth to reassign the results to the property values.

If multiple threads are acting on the same block of memory at the same time, the write operation has a great chance of being lost because one thread can overwrite the value of another thread (aka "read-Modify-write"), and the other unpleasant is that in this case you have to deal with the conflict of values and worse.

This is quite a rookie problem, and super hard to debug. If you do find someone doing this in your app, I want you to do a little favor. Search for "Tal Weiss" in your database, if there is my record, please delete it, so I will feel more secure.

Synchronized – the most basic concurrency phrase, which blocks all other threads that want to read and write a value when read and write. While it is possible, your code is destined to be diverted to DMV line.

read-write lock – a slightly more complex version of a basic Java lock that enables you to differentiate between a thread that modifies a value and needs to block other threads and a thread that only reads values and does not require a critical section. While this is more efficient (assuming a small number of write threads), it's a "pretty" way to block all other threads ' execution when you get a write lock. In fact, only when you realize that the number of write threads is extremely limited when compared to a read thread, it's really a good idea.

Volatile – this keyword is easily misunderstood and instructs the JIT compiler to re-optimize the runtime machine code so that any modifications to the property are instantly visible to other threads.

This will result in some JIT processing in the order of memory allocations this JIT compiler's favorite optimizations fail. You repeat? Yes, you did not hear wrong. The JIT compiler can change the order in which attributes are assigned. This mysterious little strategy (aka Happens-before) minimizes the number of times the program accesses the global heap, while still ensuring that your code is not affected. It's quite hidden.

So when should I use the volatile processing counter? If you have only one thread updating the value and multiple threads are reading it, using volatile is undoubtedly a really good strategy.

So why not always use it? Because it does not work well when multiple threads update properties at the same time. Since A + = B is not an atomic operation, this poses a risk of overwriting other write operations. Before Java8, you need to use Atomicinteger to deal with this situation.

Atomicinteger – This set of classes uses CAS (compare and Exchange) processor directives to update the value of the counter. Sounds good, is that really the case? No, it's not. The good side is that it can minimize the execution of other threads when it is set by a direct machine code directive. The bad side is that if it fails when it competes with other threads to set the value, it has to try again. Under high competition, this translates into a spin lock, and the thread has to continually try to set the value to loop indefinitely until it succeeds. This is not the way we want it. Let's get into the Java 8 longadders.

Java 8 Adder – This is such a cool new API that I've been talking about it all the time. It is very similar to Atomicinteger from the point of view of use, simply create a Longadder instance and use Intvalue () and add () to get and set the value. The magical place takes place behind the scenes.

The thing that this class does is that when a direct CAs fails because of a competition, it saves the delta in an internal cell object allocated for that thread , and then when Intvalue () is called, it adds the values of those temporary cells to the result and to the results. This reduces the need to return to the CAS or block other threads . What a clever thing to do!

Well, enough has been said-let's take a look at the actual performance of this class. We have set up the following benchmarks-adding a counter to 10^8 through multithreading. We run this test with a total of 10 threads-5 write operations and 5 read operations. The test machine has only one quad-Core i7 processor, so testing is bound to have some serious competition:

The code can be downloaded here to

Note that both dirty and volatile are risking some serious value covering the danger.

Summarize

• Parallel Adder has a 60%-100% performance improvement over atomic integers
• There is not much difference between the threads that perform the addition, unless they are locked
• Note the huge performance issues when you use synchronized or read-write locks – slow one or even two order of magnitude

I'd love to hear it-you already have the opportunity to use these classes in your code.

Java 8 Longadders: The right way to manage concurrency counters