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

This article mainly explains "how to protect multiple resources with a lock in java". The explanation in the article is simple and clear, easy to learn and understand. Please follow the editor's train of thought to study and learn "how to protect multiple resources with a lock in java".

Protect multiple resources protect multiple unrelated resources

If there is no relationship between multiple resources, it is to protect the replication of a resource model, which is also very simple, see the following figure:

Such as real-life bank withdrawals and password changes. The corresponding resource of the bank withdrawal operation is the "balance", and the corresponding resource of the password modification operation is the "password". There is no relationship between the balance and the password, so it is fine for each of them to use their own locks to protect their own resources.

If multiple resources are irrelevant, how beautiful the programmer's world should be, but unfortunately not, most of the resources we protect are related.

Protect the resources of multiple relationships

Take the classic bank transfer case to illustrate that when account A transfers money to account B, the balance of account A decreases by 100 yuan and the balance of account B increases by 100 yuan. if this operation is atomic, then there is a "relationship" between the resource "A balance" and the resource "B balance". Let's first take a look at the program:

Class Account {private int balance; / / transfer synchronized void transfer (Account target, int amt) {if (this.balance > amt) {this.balance-= amt; target.balance + = amt;}

Use synchronized to directly protect the transfer method, and then operate the resource "A balance" and resource "B balance".

⚠️: is that true?

Stop looking down and follow the three steps at the beginning of the article in your notebook to draw a picture. Is it the same as the following picture?

We tend to ignore the pointing relationship between locks and resources, so we take it for granted that we use lock this to protect target resources, so it does not play a protective role.

Let's assume that the initial balance of AMagol B & C account is 200 yuan, and A to B transfers 100 yuan to B, B transfers 100 yuan to C.

We look forward to the final result: account A balance: 100 yuan account B balance: 200 yuan account C balance: 300 yuan

The two operations of pseudo thread 1 "A to B transfer" and thread 2 "B to C" are executed at the same time. According to the JMM model, the current balance of thread 1 and thread 2 reading thread B is 200RMB:

Thread 1 locks the instance of A (A.this) when executing the transfer method, but not the instance of B.

Thread 2 locks the instance of B (B.this) when executing the transfer method, but not the instance of C

So thread 1 and thread 2 can enter the transfer critical section at the same time, and the model you think is right will look like this:

Remember the monitor lock rules and transitivity rules mentioned in this article on happens-before rules?

# the monitor lock rule unlocks a lock happens-before and then locks the lock # transitivity rules if A happens-before B and B happens-before C, then A happens-before C

The resource B.balance exists in two "critical areas", so this "critical section" is nonexistent for B.balance, so it does not meet the monitor lock rules, resulting in the transitivity rules not taking effect. To put it bluntly, the result of the change of the pre-ordered thread is not visible to the latter thread.

This eventually leads to:

* * the balance of account B may be 100: * * Thread 1 writes B.balance 100 (balance = 300) before Thread 2 writes B.balance (balance = 100), that is, the result of Thread 1 will be overwritten by Thread 2, resulting in a balance of 100 for final account B.

The balance of account B may be 300: contrary to the above, thread 1 writes B.balance 100 (balance = 300) and thread 2 writes B.balance (balance = 100), that is, thread 2 results in thread 1 overwriting, resulting in a balance of 300 for final account B.

Just can not get our ideal result 200, feel that life is extremely difficult, then how to do?

Correct posture

The above problem is that the locks created for resources do not protect all associated resources, so let's find a way to solve this problem. Take a look at the following code:

Class Account {private int balance; / / transfer void transfer (Account target, int amt) {synchronized (Account.class) {if (this.balance > amt) {this.balance-= amt; target.balance + = amt;}

We change the this lock to an Account.class lock. The Account.class is created when the virtual machine loads the Account class, which must be unique (the parent delegation model explains why the object is unique). All Account objects share Account.class, that is, Account.class locks protect all Account objects. Let's explain the above program with the model again.

Thank you for reading, the above is the content of "how to protect multiple resources with a lock in java". After the study of this article, I believe you have a deeper understanding of the problem of how to protect multiple resources with a lock in java, 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.