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

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

Will two objects refer to each other by GC?

Will still be GC. Because JVM determines whether the object is GC according to the reachability of the object in the graph with GC root as the root node. Two objects that reference each other, although the number of references is not 0, but if there is no reference relationship with other objects, that is, an island, it will still be GC.

The objects in java that can be used as GC Root are

Objects referenced in the virtual machine stack (table of local variables)

Objects referenced by static properties in the method area

Objects referenced by constants in the method area

Objects referenced in the local method stack (Native objects)

Optimistic lock and pessimistic lock

Pessimistic lock

Pessimistic lock (Pessimistic Lock), as its name implies, is very pessimistic. Every time you go to get the data, you think that someone else will modify it, so you lock it every time you get the data, so that others will block the data until it gets the lock. Pessimistic locks: assume that concurrency conflicts occur, shielding all operations that may violate data integrity. Java synchronized is an implementation of pessimistic lock. Every time a thread modifies data, it acquires the lock first, ensuring that only one thread can manipulate the data at the same time, while other threads will be block.

Optimistic lock

Optimistic lock (Optimistic Lock), as the name implies, is very optimistic. Every time you go to get the data, you think that others will not change it, so you will not lock it, but when you submit the update, you will judge whether others have updated the data during this period. Optimistic locks are suitable for application scenarios with more reads and less writes, which can improve throughput. Optimistic locks: assuming that there are no concurrency conflicts, only check for violations of data integrity when committing operations.

Generally speaking, there are two ways to lock optimism:

It is implemented using the data version (Version) recording mechanism, which is the most common implementation of optimistic locking. What is the data version? That is, to add a version ID to the data, usually by adding a numeric type "version" field to the database table. When the data is read, the value of the version field is read out together, and each time the data is updated, the version value is added. When we submit the update, we judge that the current version information recorded in the database table is compared with the version value taken out for the first time, and if the current version number of the database table is equal to the version value taken out for the first time, it will be updated, otherwise it is considered to be out-of-date data. Use a time stamp (timestamp).

The second implementation of optimistic locking is similar to the first. It also adds a field to the table that requires optimistic lock control. The name does not matter. The field type uses a timestamp, similar to the above version. The timestamp of the data in the current database is checked when the update is submitted and compared with the timestamp taken before the update. If it is consistent, OK, otherwise it is a version conflict. The atomic package in Java JUC is an implementation of optimistic locking, and AtomicInteger implements thread-safe self-increment through CAS (Compare And Set) operations.

ThreadLocal memory leak problem, how to prevent

The implementation of ThreadLocal is like this: each Thread maintains a ThreadLocalMap mapping table, the key of this mapping table is the ThreadLocal instance itself, and value is the Object that really needs to be stored.

In other words, ThreadLocal itself does not store values, it just acts as a key to let threads get value from ThreadLocalMap. It is worth noting that the dotted line in the figure indicates that ThreadLocalMap uses the weak reference of ThreadLocal as the Key, and the weakly referenced object is recycled during GC.

The root cause of the ThreadLocal memory leak is that because the life cycle of ThreadLocalMap is as long as that of Thread, it will cause a memory leak if the corresponding key is not manually deleted, not because of weak references. Based on the above analysis, we can understand the causes and consequences of ThreadLocal memory leaks, so how to avoid memory leaks?

Every time you finish using ThreadLocal, you call its remove () method to clear the data. In the case of thread pools, not cleaning up the ThreadLocal in a timely manner is not only a memory leak problem, but also may lead to business logic problems. So, using ThreadLocal is the same as unlocking after locking, cleaning up after using it.

Opening and closing principle

Definition: a software entity such as classes, modules, and functions should be open to extensions and closed to modifications. The cause of the problem: during the life cycle of the software, when the original code of the software needs to be modified due to changes, upgrades, maintenance and other reasons, errors may be introduced into the old code, or we may have to ReFactor the whole function. and the original code needs to be retested.

Solution: when the software needs to change, try to achieve the change by extending the behavior of the software entity, rather than by modifying the existing code.

The opening and closing principle is the most basic design principle in object-oriented design, which guides us how to establish a stable and flexible system. The opening and closing principle is probably the most vaguely defined of the six principles of the design pattern. it only tells us that it is open to extension and closed to modification, but it does not tell us exactly how to open it to extension and close it to modification. In the past, if someone told me, "you must follow the principle of opening and closing when you design," I would feel that he didn't say anything, but he seemed to have said everything. Because the principle of opening and closing is really too empty.

After thinking carefully and reading many articles on design patterns, I finally have some understanding of the opening and closing principle. In fact, we follow the first five principles of design patterns, and the purpose of using 23 design patterns is to follow the principle of opening and closing. In other words, as long as we abide by the first five principles, the designed software is naturally in line with the opening and closing principle, which is more like the "average score" of the first five principles. The average score is naturally high, indicating that the software design abides by the opening and closing principle well; if the first five principles are not observed well, it means that the opening and closing principle is not well observed.

In fact, the open-close principle is nothing more than to express such a meaning: build the framework with abstraction and extend the details with implementation. Because the abstraction has good flexibility and wide adaptability, as long as the abstraction is reasonable, it can basically maintain the stability of the software architecture. As for the changeable details in the software, we use the implementation class derived from the abstract to expand. When the software needs to change, we only need to derive a new implementation class according to the requirements to expand it. Of course, the premise is that our abstraction should be reasonable and be forward-looking and predictable to the changes in requirements.

At this point, recall that the five principles mentioned above tell us exactly how to build the framework with abstraction and expand the details with implementation: the principle of single responsibility tells us that the implementation class has a single responsibility; the principle of Richter substitution tells us not to destroy the inheritance system; the principle of dependency inversion tells us to program for interfaces; and the principle of interface isolation tells us to simplify singleness when designing interfaces. Demeter's law tells us to reduce coupling. The principle of opening and closing is the general principle, and he told us to open it to expansion and close it to modification.

Idempotent design

The core technology of high concurrency-idempotent implementation scheme

Background there are many operations in our actual system, no matter how many times they are done, they should produce the same effect or return the same result. For example:

The front end repeatedly submits the selected data, and the background should produce only one response to this data.

When we initiate a payment request, we should only deduct the money from the user's account once, and when we encounter a network retransmission or system bug retransmission, we should deduct the money only once.

Send a message only once. If the same message is sent to the user, the user will cry.

To create a business order, you can only create one business request at a time, but there will be a big problem if you create multiple business orders.

And many other important situations, these logics need idempotent properties to support.

2. Idempotent concept idempotent (idempotent, idempotence) is a mathematical and computer concept, which is common in abstract algebra.

In programming. The characteristic of an idempotent operation is that the effect of arbitrary execution is the same as that of one execution. Idempotent functions, or idempotent methods, are functions that can be executed repeatedly with the same parameters and get the same results. These functions do not affect the state of the system, and there is no need to worry that repeated execution will change the system. For example, the getUsername () and setTrue () functions are idempotent functions.

The more complex operation idempotent guarantee is realized by using a unique transaction number (serial number).

My understanding: idempotence is an operation, no matter how many times it is executed, the effect and the return result are the same.

III. Technical proposal

Query operation

Query once and query multiple times, in the case of unchanged data, the query result is the same. Select is a natural idempotent operation.

Delete operation

Delete operation is also idempotent, delete once and many times is to delete the data. (note that different results may be returned, deleted data does not exist, 0 is returned, multiple items of deleted data are returned, and multiple results are returned)

Unique index

To prevent new dirty data such as: Alipay capital account, Alipay also has a user account, each user can only have one capital account, how to prevent users from creating multiple capital accounts, then add a unique index to the user ID in the capital account table, so a user successfully adds a fund account record.

Key points: unique index or unique combined index to prevent dirty data from new data (when there is a unique index in the table and a new error is reported at the same time, it can be queried again, the data should already exist and the result can be returned)

Token mechanism

Prevent repeated submission of business requirements on the page: the data of the page can only be clicked and submitted once. The reason: repeated clicks, network retransmission, or nginx retransmission may lead to repeated submission of data. Solution: cluster environment: use token plus redis (redis single thread, processing needs to queue) single JVM environment: use token plus redis or token plus jvm memory processing process:

Before the data is submitted, the token,token of the application to the service should be put into redis or jvm memory, and the valid time of token

Check token at backend after submission, delete token at the same time, and generate new token to return token feature: to apply for one-time validity, you can limit the current.

Note: redis should use delete operation to judge token. Successful deletion means that token verification is passed. If you use select+delete to verify token, it is not recommended to use it because of concurrency problems.

Pessimistic lock

When obtaining data, add a lock to obtain select * from table_xxx where id='xxx' for update; Note: the id field must be a primary key or a unique index, otherwise it is a locked table, and pessimistic locks that can kill people are usually used with transactions, and the data locking time may be very long, so choose according to the actual situation.

Optimistic lock

Optimistic locking only locks the table at the moment the data is updated, but does not lock the table the rest of the time, so it is more efficient than pessimistic locking.

Optimistic locks can be implemented in a variety of ways through version or other status conditions:

Update table_xxx set name=#name#,version=version+1 where version=#version# is implemented with the version number as follows (from the Internet):

Through the condition limit update table_xxx set avai_amount=avai_amount-#subAmount# where avai_amount-#subAmount# > = 0 requirement: quality-#subQuality# > =, this scenario is suitable for not using version number, only updating is for data security check, suitable for inventory model, deducting share and rolling back share, and has higher performance.

Note: for the update operation of optimistic lock, it is best to update it with a primary key or a unique index, which is a row lock, otherwise the table will be locked when updating, and the above two sql will be changed to the following two better update table_xxx set name=#name#,version=version+1 where id=#id# and version=#version# update table_xxx set avai_amount=avai_amount-#subAmount# where id=#id# and avai_amount-#subAmount# > = 0

Distributed lock

Or take the example of inserting data. If the distribution is a system, it is difficult to build a globally unique index. For example, unique fields cannot be determined. At this time, a distributed lock can be introduced. Through a third-party system (redis or zookeeper), the data is inserted or updated in the business system, the distributed lock is acquired, and then the lock is released. In fact, the idea of multi-thread concurrent locking is introduced into multiple systems. That is, it has to be solved in the distributed system.

Key points: a long process requires that it cannot be executed concurrently. A distributed lock can be acquired according to a flag (user ID+ suffix, etc.) before the process is executed, and the lock will fail when other processes are executed, that is, only one of the processes can be executed successfully at a time. After the execution is completed, release the distributed lock (the distributed lock is provided by the third party system).

Select + insert background systems with low concurrency, or some tasks JOB, in order to support idempotence and repeated execution, the simple processing method is to first query some key data to determine whether it has been executed, and then carry out business processing. Note: do not use this method in the core high concurrency process.

The state machine idempotent in the business related to the design document, or the business related to the task, will definitely involve the state machine (state change diagram), that is, there is a state on the business document, and the state will change under different circumstances. in general, there is a finite state machine. At this time, if the state machine is already in the next state, there is a change of the previous state, which cannot be changed in theory. In this way, the idempotent of the finite state machine is guaranteed.

Note: orders and other documents, there is a long state flow, it is necessary to have a deep understanding of the state machine, which is of great help to improve the design ability of the business system.

How to ensure that the api with external interface is idempotent like the payment interface provided by UnionPay: when you need to access merchants to submit payment requests, it is attached: source source, seq serial number source+seq makes a unique index in the database to prevent multiple payments (concurrently, only one request can be processed)

Important: in order to support idempotent calls, two fields must be passed in the API, one is the source source and the other is the source serial number seq. These two fields are jointly and uniquely indexed in the provider system, so when a third party is called, check in the local system to see whether it has been processed and return the corresponding processing result; if it has not been processed, the corresponding processing is carried out and the result is returned. Note that in order to be idempotent and friendly, you must first inquire whether the business has been processed, and if you do not query and insert it directly into the business system, you will report an error, but it has actually been handled.

At this point, the study of "what are the idempotent interview questions of JAVA" 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.