Shulou(Shulou.com)06/02 Report--

This article mainly explains "Java multithreaded concurrent programming and lock principle is what", the content of the article is simple and clear, easy to learn and understand, now please follow the editor's train of thought slowly in depth, together to study and learn "Java multithreaded concurrent programming and lock principle is what" it!

one。 Preface

Recently, the project encountered the situation of multi-thread concurrency (concurrent order scrambling & inventory recovery parallel). There is no problem for the code to run under normal conditions, but under the high concurrency stress test, there will be various problems such as overissued inventory / total inventory mismatch with sku inventory.

After using the current limiting / locking scheme, the problem is solved.

two。 Optimistic lock & pessimistic lock

1. Optimistic lock

As the name implies, it is very optimistic. Every time I go to get the data, I think that others will not modify it, so it will not be locked. But when updating, I will judge whether others have updated the data during this period. We can use mechanisms such as version number (version).

For example: mybatis-plus comes with plug-in OptimisticLockerInterceptor, which adds a version field to the database table, and each time the database mp is updated, it will automatically add 1 to the version field. If the value of the version field is found to be inconsistent with the latest value in the database when the update is submitted, the submission fails.

two。 Pessimistic lock

Pessimistic locks always assume the worst, and every time they go to get the data, they think that someone else will modify it, so they lock it every time they get the data, so that others will block until it gets the lock if they want to get it.

Many of these locking mechanisms are used in traditional MySQL relational databases, such as row locks, table locks, read locks, write locks and so on.

The implementation of Java's synchronous synchronized keyword is a typical pessimistic lock.

3. Summary

Pessimistic locks are suitable for scenarios with many write operations. Adding a lock first can ensure that the data is correct during the write operation.

Optimistic lock is suitable for scenarios with many read operations, and the characteristic of unlocking can greatly improve the performance of read operations.

three。 Exclusive lock & shared lock

1. Exclusive lock

Means that the lock can only be held by one thread at a time.

For example: Synchronized and ReentrantLock, which are also pessimistic locks

two。 Shared lock

Means that the lock can be held by multiple threads, allowing multiple threads to acquire it at the same time.

For example: Semaphore and ReadWriteLock and countdownlatch, where the read lock is a shared lock and the write lock is the exclusive lock.

3. Summary

The shared lock of the read lock ensures that concurrent reads are very efficient, and the processes of reading and writing are mutually exclusive.

Exclusive lock and shared lock are also realized through AQS, through the implementation of different methods to achieve exclusive or shared.

four。 Fair lock & unfair lock

1. Fair lock

Check to see if there are any threads waiting in the queue before adding the lock, and if so, give priority to the first thread on a first-come-first-served basis.

two。 Unfair lock

When the thread adds a lock, it directly attempts to acquire the lock, and if it fails to get it, it automatically waits at the end of the queue.

3. Summary

More often, unfair locks are used directly: the performance of unfair locks is 5-10 times higher than that of fair locks, because fair locks need to maintain a queue in multi-core cases. If the current thread is not the first one in the queue, it increases the number of thread switches.

Five. Java thread lock

Because multiple threads share the resources and address space of their own process, there is a problem: what if multiple threads want to access a resource at the same time?

In Java concurrent programming, it is often encountered that multiple threads access the same shared resource. At this time, developers must consider how to maintain data consistency, which is the source of Java locking mechanism (synchronization problem).

Java provides a variety of ways to implement multithreaded locking mechanisms, including:

Synchronized ReentrantLock Semaphore AtomicInteger et al.

Each mechanism has its own advantages and disadvantages and its own applicable scenarios, and their characteristics must be skillfully mastered in order to be handy in the development of Java multithreaded applications.

1.Synchronized

The synchronized keyword is often used to maintain data consistency in Java. The synchronized mechanism is to lock the shared resources, and only the thread that gets the lock can access the shared resources, so that the access to the shared resources can be forced to be sequential.

Java developers all know synchronized, and it is very simple to use it to achieve multi-thread synchronization. As long as the keyword is added to the method, class, or code block of the other party that needs synchronization, it can ensure that at most one thread executes the synchronization code of the same object at the same time, and that the decorated code will not be disturbed by other threads in the execution process. The code decorated with synchronized has atomicity and visibility, and is used frequently in programs that need process synchronization, which can meet the general process synchronization requirements.

Synchronized (obj) {/ / method. . }

The mechanism of synchronized implementation depends on JVM at the software level, so its performance will be improved with the continuous upgrade of the Java version.

Many optimizations have been carried out in Java1.6,synchronized, such as adaptive spin, lock elimination, lock coarsening, lightweight lock and biased lock, and the efficiency has been improved essentially. After that, the implementation mechanism of this keyword is optimized in Java1.7 and 1.8.

It should be noted that when a thread waits for a lock through synchronized, it cannot be interrupted by Thread.interrupt (), so the program design must check to make sure it is reasonable, otherwise it may cause the embarrassment of thread deadlock.

Finally, although there are many locking mechanisms implemented by Java, and some of them perform better than synchronized, it is highly recommended to use this keyword in multithreaded applications because it is easy to implement and the follow-up work is done by JVM with high reliability. Other mechanisms, such as ReentrantLock, are considered only when it is determined that the locking mechanism is the performance bottleneck of current multithreaded programs.

Conclusion: when the competition for resources is not very fierce, and there is occasional synchronization, synchronized is very appropriate. The reason is that compilers usually optimize synchronize as much as possible, and the readability is very good.

2.ReentrantLock

A reentrant lock, as its name implies, can be repeatedly entered by a thread for acquisition operations.

ReentantLock inherits the interface Lock and implements the methods defined in the interface. In addition to completing all the work that synchronized can do, it also provides methods to avoid multithreaded deadlocks, such as responding to interrupt locks, polling lock requests, timing locks, and so on.

The mechanism of Lock implementation depends on the special CPU specification, which can be considered as free from the constraints of JVM, and the underlying implementation can be completed through other language platforms. In multithreaded applications with small concurrency, the performance of ReentrantLock is almost the same as that of synchronized, but under the condition of high concurrency, the performance of synchronized will rapidly decline dozens of times, while the performance of ReentrantLock can still maintain the same level.

Therefore, we recommend using ReentrantLock in the case of high concurrency.

ReentrantLock introduces two concepts: fair lock and unfair lock.

Fair lock means that the allocation mechanism of the lock is fair, and usually the thread that makes the acquisition request to the lock first is assigned to the lock first. On the contrary, the mechanism of JVM assigning locks according to the principle of random and nearest is called unfair lock.

ReentrantLock provides a way to initialize fair locks in the constructor, which defaults to unfair locks. This is because the efficiency of the actual implementation of unfair locks is much higher than that of fair locks, and the allocation mechanism of unfair locks is most commonly used unless the program has special needs.

ReentrantLock carries out locking and unlocking operations through the methods lock () and unlock (). Unlike the mechanism that synchronized will be automatically unlocked by JVM, ReentrantLock needs to be unlocked manually. In order to avoid the situation that the program cannot be unlocked normally due to an exception, the unlocking operation must be performed in the finally control block when using ReentrantLock. The usual usage is as follows:

/ * initialize an unfair lock (this lock applies only to a single instance) * / private static Lock lock = new ReentrantLock (false); void test () {try {lock.lock (); / /. Execute business logic} finally {lock.unlock ();}}

Summary: when the competition for resources is not fierce, the performance is slightly worse than synchronized. But when synchronization is very intense, the performance of synchronized can be degraded dozens of times at once, and ReentrantLock can remain normal. ReentrantLock is used in high concurrency cases.

Note: the problem that Spring comments and synchronization locks cannot be synchronized is resolved

3.Semaphore (semaphore)

The above two lock mechanism types are "mutex", which is a special case of process synchronization relationship, which means that there is only one critical resource, so at most one thread can be serviced at the same time. However, in practical complex multithreaded applications, there may be multiple critical resources, so we can access multiple critical resources with the help of Semaphore semaphores.

Semaphore can basically do all the work of ReentrantLock, using a similar method, using acquire () and release () methods to obtain and release critical resources.

According to the actual measurement, the Semaphone.acquire () method defaults to the responsive interrupt lock, which is consistent with the effect of ReentrantLock.lockInterruptibly (), that is to say, it can be interrupted by the Thread.interrupt () method while waiting for the critical resource.

In addition, Semaphore also implements the function of polling lock request and timing lock, except that the method name tryAcquire is different from tryLock, and its usage is almost the same as ReentrantLock. Semaphore also provides a mechanism for fair and unfair locks, which can also be set in the constructor.

The lock release operation of Semaphore is also done manually, so as with ReentrantLock, in order to prevent the thread from releasing the lock normally because of throwing an exception, the lock release operation must also be done in the finally code block.

/ * * define an unfair shared lock * / public static Semaphore LOCK = new Semaphore (5, false); void test () {try {/ / obtain license LOCK.acquire ();} finally {/ / release license LOCK.release ();}}

Thank you for your reading, the above is "what is the principle of Java multithreaded concurrent programming and locking". After the study of this article, I believe you have a deeper understanding of what the principle of Java multithreaded concurrent programming and locking is, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.