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

This article mainly introduces "what are the methods of dealing with concurrent problems in Java work". In daily operation, I believe that many people have doubts about the methods of dealing with concurrent problems in Java work. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful for you to answer the doubts of "what are the methods of dealing with concurrent problems in Java work?" Next, please follow the editor to study!

Problem recurrence

1. "device A" strange split.

Time went back to a long time ago in the middle of the night, when the multimedia advertising control system I developed had just been put into production, and in the first offline fresh store opened by the company, dozens of multimedia hardware devices, large and small, had been connected to the network. I am registering and accessing the multimedia advertising control system that has already been online.

The registration process is summarized as follows:

After each device is registered in the system, a new record will be added to the database device table to store the information of the device.

Everything was going on in an orderly way until the registration of device A broke the silence of the tacit understanding.

After the registration of device A, I suddenly found that two new records were added to the database equipment table, and they were exactly the same!

I started to think I was blind.

If you take a closer look, you can see that two new ones have been added, and even the unique identification of the equipment (underline, which will be tested later) is exactly the same as the creation time!

Looking at the screen, I was lost in thought.

Why are there two?

In my registration logic, I will check whether the device already exists in the database before putting it into the database. If it exists, update the existing one, and add it if it does not exist.

So I am puzzled. According to this logic, where does the second identical data come from?

two。 Concurrent requests behind the truth

After some investigation and reflection, I found that the problem may lie in the registration request.

When device A sends http registration requests to the cloud, it may send multiple identical requests at the same time.

At that time, the CVM was deployed on multiple Docker containers. By checking the logs, it was found that two containers received registration requests from device A.

From this, I speculate:

Device A sent two registration requests at the same time. These two requests were sent to different containers on the cloud at the same time. According to my registration logic, after receiving the registration request, these two containers queried the device table in the database at the same time. At this time, there is no record of device An in the device table, so both containers have performed new operations because of the high speed. So there is no difference between the two new records in terms of creation time accurate to seconds.

3. Concurrently new extensions

Since concurrent new operations can cause problems, will concurrent update operations be problematic?

Solution method

Solve concurrent additions

1. Database unique Index (UNIQUE INDEX)

When creating a table in the database, create a unique index on the unique fields (such as the unique identification of the device mentioned above), or create a joint unique index on several fields that are unique when combined.

In this way, as long as one addition is successful, the other new operations will fail because of the java.sql.SQLIntegrityConstraintViolationException thrown by the database. We just need to deal with the failure of the addition.

Note that the field of the unique index needs to be non-empty, because the null value of the field will invalidate the unique index constraint.

2. Java distributed lock

By introducing the distributed lock into the program, the distributed lock needs to be acquired before the new operation is carried out, and the success can be obtained before it can continue, otherwise the new operation fails.

This can also solve the problem of data duplication caused by concurrent insertion, but the introduction of distributed locks also increases the complexity of the system. If there are unique fields on the data to be stored, the method of unique index is recommended.

In the process of building distributed locks, we need to use Redis. Here we take the distributed locks used when registering devices as an example.

Distributed lock simple question and answer:

Q: what on earth is the lock?

A: a lock is essentially a string generated based on a specific rule in Redis (fixed prefix + unique identification of the device in the example), which means that each device has its own corresponding lock when it registers, because there is only one lock. Even if multiple identical registration requests for the device arrive at the same time, only the request that acquires the lock can proceed successfully.

Q: what is an acquisition lock?

A: for the same device, the string generated based on the same rules (later referred to as the string by Key) is always the same. Before performing the new operation, go to Redis to query whether the Key exists. If it already exists, it means the acquisition of the lock failed. If it does not exist, the Key is stored in the Redis. If the storage succeeds, the acquisition of the lock succeeds. If the storage fails, it still means the acquisition of the lock failed.

Q: how does the lock work?

A: as mentioned earlier, for the same device, the string (Key) generated based on the same rules is always the same. Before the current thread performs the new operation, query whether the Key exists in the Redis. If it already exists, it means that another thread has successfully acquired the lock and is doing the new operation that the current thread wants to do, so the current thread does not need to perform subsequent operations (yes, you are superfluous).

When this Key does not exist, it means that no other thread has acquired the lock, then the current thread can proceed to the next step-- quickly deposit the Key in the Redis. When the Key storage fails, it means that another thread has preempted the Key and successfully acquired the lock. The current thread is one step late and the work that you want to do is done by others (the current thread can be removed).

When and only if the Key is successfully saved in Redis, it means that the current thread has finally acquired the lock and can rest assured to proceed with the following new operation. During this period, other threads that want to do the same new operation have no choice but to exit because they cannot acquire the lock: remember to release the lock (delete the Key from the Redis) after the current thread of wave:, finishes execution.

The distributed lock code used when registering is as follows:

Public class LockUtil {/ / A utility class @ Autowired private RedisService redisService; / / that simply encapsulates the underlying set/get method of redis generates a fixed prefix for the lock and reads the value @ Value ("${redis.register.prefix}") private String REDIS_REGISTER_KEY_PREFIX from the configuration file. / / Lock expiration time: that is, the longest time the thread can operate after acquiring the lock, after which the lock is automatically released (invalidated) Someone else can restart to acquire the lock for corresponding operation / / set the lock expiration time in order to prevent a thread from accidentally hanging up during the execution of the task after successfully acquiring the lock, causing the lock to never be released @ Value ("${redis.register.timeout}") private Long REDIS_REGISTER_TIMEOUT / * obtain the Mac address of the distributed lock when the device is registered * @ param deviceMacAddress device * @ return * / public boolean getRegisterLock (String deviceMacAddress) {if (StringUtils.isEmpty (deviceMacAddress)) {return false;} / / get the string (Key) String redisKey = getRegisterLockKey (deviceMacAddress) corresponding to the lock of the device / / start trying to acquire a lock / / if the current task lock key already exists, it means that another thread is performing tasks on the device during the current time, and the current thread can retire if (redisService.exists (redisKey)) {return false } / / start trying to lock, note that you need to use the SETNX instruction here (because there may be multiple threads arriving at the same time to start locking, use SETNX to ensure that one and only one setting returns successfully) boolean setLock = redisService.setNX (redisKey, null) / / start trying to set the lock expiration time. If the thread has not released the lock at the expiration time, the Redis that saves the lock ensures that the lock is finally released, so as to avoid the deadlock / lock expiration time setting. You can evaluate the normal use of the thread to execute the task, and slightly larger boolean setExpire = redisService.expire (redisKey, REDIS_REGISTER_TIMEOUT). / / the current thread is considered to have acquired the lock successfully only when both the lock setting and the expiration time setting are successful, otherwise the lock acquisition failure if (setLock & & setExpire) {return true;} / / manually clears the lock Key redisService.del (redisKey) just set when the lock setting success occurs but the expiration time setting fails. Return false;} / * Delete the distributed lock at the time of device registration * @ param deviceMacAddress device Mac address * / public void delRegisterLock (String deviceMacAddress) {redisService.del (getRegisterLockKey (deviceMacAddress)) } / * obtain the key * @ param deviceMacAddress device mac address of the distributed lock when the device is registered (the mac address of each device is unique) * @ return * / private String getRegisterLockKey (String deviceMacAddress) {return REDIS_REGISTER_KEY_PREFIX + "_" + deviceMacAddress;}}

Examples of using locks in normal registration logic are as follows:

Public ReturnObj registry (@ RequestBody String device) {Devices deviceInfo = JSON.parseObject (device, Devices.class); / / locking before starting registration boolean registerLock = lockUtil.getRegisterLock (deviceInfo.getMacAddress ()); if (! registerLock) {log.info ("failed to acquire device registration lock, current registration request failed!") ; return ReturnObj.createBussinessErrorResult ();} / / lock successfully, start to register the device ReturnObj result = registerDevice (deviceInfo); / / after registering the device, delete the lock lockUtil.delRegisterLock (deviceInfo.getMacAddress ()); return result;}

Resolve concurrent updates

1. Do concurrent updates really cause problems?

When simultaneous updates or previous updates have no impact on the business, no processing is required so as not to increase the complexity of the system in vain.

two。 Optimistic lock

Repeated updates can be avoided by optimistic locking, that is, adding a version field to the database table, querying the record and writing down the queried version number before doing the update operation, and then judging whether the previously queried version number is consistent with the version number of the record in the current database during the actual update operation. If the same, it means that during the period from query to update of the current thread No other thread updates this record If it is inconsistent, it means that other threads have changed the record during this period, and the update operation of the current thread is no longer safe and can only be abandoned.

Determine the SQL example:

Update a_table set name=test1, age=12, versionversion=version+1 where id = 3 and version= 1

Optimistic locks are more efficient than pessimistic locks in determining whether the data they read from the database has been modified by others at the last update moment, because during the period before the current thread query and the final update, other threads can read the same record as usual and can update it first.

Pessimistic lock

Pessimistic locks are the opposite of optimistic locks, which are locked when the current thread queries the data to be updated, and other threads are not allowed to modify the data before the update is completed.

By using select... For update came to tell the database, "I'm going to update this data right now. Lock it up for me."

Note: FOR UPDATE only applies to InnoDB and can only take effect in a transaction. When the query condition has an explicit primary key and has this record, it is a row lock (row lock, only locks this row of data located according to the query condition). When the query condition has no primary key or the primary key is unclear, it is table locking (table lock, locking the whole table will result in that the data of the whole table cannot be changed during the lock period). Therefore, when using pessimistic locking, it is best to explicitly locate the query condition to a row or rows, not to cause a full table lock.

At this point, the study on "what are the ways to deal with concurrent problems in Java work" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.