Shulou(Shulou.com)05/31 Report--

In this issue, the editor will bring you a defect about how to realize the CAS non-lock singleton. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

What we're going to talk about today is the unlocked implementation singleton pattern and the disadvantages of this singleton implementation of CAS.

The traditional seven singleton models are roughly as follows:

They are all implemented with locks. But what if the interviewer asks you during the interview how to use a non-lock to implement a singleton?

The answer is the implementation shown in the following figure.

This is the realization of a Daniel on the Internet, and his single example of this unlocked CAS implementation is very good. But it may not be used by anyone, which is a little more complicated than using a lock, which is why it is not included in the seven capitals of the singleton pattern. I added two lines of code to his foundation, that is, his constructor.

I mainly want to see how many times it has been instantiated. With these two lines of code, it is convenient for me to observe the console and count the total number of instantiations.

Then, my test code is as follows:

About CountDownLatch will not, you can see my "CountDownLatch stress testing tutorial" article.

The main thing I want to test here is whether the unlocked CAS singleton mode creates multiple objects.

Running the main method above, I took a screenshot of the final result.

CAS updates the corresponding values in memory in an atomic way, thus ensuring the synchronization of shared variable update operations in a multithreaded environment. Indeed, this approach ensures that you get the same instance every time you call the getInstance () method. Therefore, from the point of view of functional implementation, this approach has achieved the desired goal. However, after analysis and testing, it has been found that this approach has some unexpected drawbacks: it may create more than one object.

It is true that the operation of CAS itself is atomic, but the method of wrapping the CAS instruction is not fully synchronous, and of course, the parameter calculation is not mutually exclusive before the method containing the CAS instruction is called! When a thread tests instance.get () = = null to get true, it must call new Singleton () next. Because this is not part of the CAS method, but its parameters. Before calling a method, you need to push its parameters onto the stack, and of course, you need to evaluate the parameter expression, so it is not difficult to predict the result.

The difference between a CAS and a lock is that it is non-blocking, that is, it does not wait for a condition, but is bound to execute it, resulting in either success or failure. Its operating time is predictable. If our goal is to execute CAS successfully, it needs to be executed in a loop until it succeeds, and a lot of preparation work based on success expectations is worthwhile, but if we don't want the operation to be successful, the preparation for a successful operation is wasted.

The above is a defect of how the CAS non-lock is shared by the editor. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

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.