Three implementation example codes of Java high concurrency lock

Beginner skill - optimistic lock

Optimistic lock is suitable for such a scenario: reading will not conflict, writing will conflict. The frequency of simultaneous reading is much higher than that of writing.

Take the following code as an example to implement pessimistic lock:

Implementation of optimistic lock:

Intermediate skill - string intern()

Optimistic locking cannot solve the problem of a large number of write conflicts, but in many scenarios, the lock is actually only for a user or an order. For example, a user must create a session before performing subsequent operations. However, due to network reasons, the request to create a user session and subsequent requests arrive almost at the same time, and parallel threads may process subsequent requests first. Generally, you need to lock the user sessionmap, such as the optimistic lock above. In this scenario, it can be said that the lock is limited to the user itself, that is, from the original

Change to:

This comparison is similar to the concepts of database table lock and row lock. Obviously, the concurrency of row lock is much higher than that of table lock.

Use string Inter () is a concrete implementation of this idea. The string class maintains a string pool. When the intern method is called, if the pool already contains a string equal to this string object (determined by the equals (object) method), the string in the pool is returned. It can be seen that when strings are the same, string Intern () always returns the same object, so it implements locking the same user. Because the granularity of lock is limited to specific users, the system obtains the maximum concurrency.

CopyOnWriteMap？

Now that we talk about the concept of "row lock similar to that in database", we have to mention mvcc. The copyonwrite class in Java implements mvcc. Copy on write is such a mechanism. When we read shared data, we read it directly without synchronization. When we modify the data, we copy a copy of the current data, and then modify it on this copy. After that, we use the modified copy to replace the original data. This method is called copy on write.

However, JDK does not provide copyonwritemap. Why? The following is a good answer: why do you need copyonwritemap when you already have concurrenthashmap?

Fredrik bromee wrote

I guess this depends on your use case,but why would you need a CopyOnWriteMap when you already have a ConcurrentHashMap?

For a plain lookup table with many readers and only one or few updates it is a good fit.

Compared to a copy on write collection:

Read concurrency:

Equal to a copy on write collection. Several readers can retrieve elements from the map concurrently in a lock-free fashion.

Write concurrency:

Better concurrency than the copy on write collections that basically serialize updates (one update at a time). Using a concurrent hash map you have a good chance of doing several updates concurrently. If your hash keys are evenly distributed.

If you do want to have the effect of a copy on write map,you can always initialize a ConcurrentHashMap with a concurrency level of 1.

Advanced tips - class concurrenthashmap

String. The defect of inter() is that a string pool maintained by the class string is placed in the JVM perm area. If there are too many users, the string placed in the string pool is uncontrollable, which may lead to oom errors or too many full GCs. How can you control the number of locks and reduce the granularity lock at the same time? Use Java concurrenthashmap directly? Or do you want to add more subtle control? Then you can learn from the method of concurrenthashmap to divide the objects to be locked into multiple buckets, and each bucket is locked with a lock. The pseudo code is as follows:

The above is the whole content of this article. I hope it will be helpful to your study, and I hope you can support programming tips.