In the development process, sometimes in order to solve the multi-threaded competition problem need to lock, usually locked object is class,object,method, but at a certain time we need more granular lock, that is, according to different input parameters to lock different resources, This will only compete if the different lines of this method are called Cheng.
For example, a simple example: Assume that the system provides the user with a loan and a monthly limit. The monthly borrowing records are recorded in the Transaction_detail table, when a user needs to borrow, we need to do something:
Method:borrow_money
1, to determine whether the user reached the borrowing limit, this month has borrowed amount: select sum (amount) from Transaction_detail where user_id=xx;
2. Other business Processing
3. Insert Transaction_detail
But the above three steps are not atomic, that is, assuming a user limit of 3w, has borrowed 1.5w (also can borrow 1.5w), now has two threads A, b, each thread needs to borrow 1w.
When thread a finishes the first step, thread a hangs at this point.
Thread 2 began to execute, because at this time the borrowing 1w< can borrow 1.5w, so thread 2 execution went on a successful loan 1w, inserted as a new loan record.
A thread continues to execute 2, 3 steps also successfully loan 1w, so that the user's loan volume of the month has reached 3.5w greater than the total limit (against the monthly 3w limit). The result is that the above 3 steps are non-atomic, and it is likely that our loan status, which we have borrowed and inserted into the borrowing record, is different from the amount of money that we have been able to determine during the month.
So we need to lock up the three steps above, but if we borrow_money the appeal method to use synchronized, it will cause a very serious efficiency problem, because all the threads of the entire system are competitive in executing Borrow_money. This can cause system performance bottlenecks.
So we can use a finer-grained locking mechanism. A particular string can be locked to ensure the atomicity of the operation while reducing the competition of the resources of the thread, this particular string needs to be associated with the user one-to-one, while ensuring that the system does not affect other operations, so you can use: special string (to ensure that the string has a special) + ID.
And our strings need to be taken to the JVM's constant pool to ensure that the string obtained for the same user is an object.
String Synckey = ("Borrow_money_" + userId). Intern (); synchronized (Synckey) {//1, judging the amount of borrowing the user has borrowed this month: select SUM (amount) from TR Ansaction_detail where user_id=xx; 2, other business processing//3, insert Transaction_detail}
This resolves exclusive access to the same key, but this is limited to the same JVM, and if the server is deployed on the cluster, it will not achieve the desired effect.
At this point, the monthly total borrowing information can be recorded in a table, so that in the judgment and operation can be based on this record to determine the status
Or use distributed locks, such as zookeeper, for management.
An implementation of the atomicity of Java Business (key exclusive access)