I checked out the design mode today and found that the previous understanding of the singleton mode was superficial and thread security was not taken into account. I did not consider performance when thread security was taken into account, of course, the system I encountered does not consider concurrency performance very much, so it does not matter. When I see the singleton mode, I searched the internet and posted a good post, I sorted out the singleton mode and gave a result.
Post address: http://blog.csdn.net/zhangerqing/article/details/8194653
The premise is that thread security can be considered in two cases. This is an implementation of lazy and hunger.
1. The performance is not very good. Every time you lock the object, if you encounter the same performance issues as the system I encountered, you will not consider performance issues. In fact, this is not a problem, but it is not good. As mentioned in Oracle Advanced Programming, your SQL statement can complete tasks correctly, but it does not mean that it can complete tasks well.
2. we only want to instantiate the object during the first getinstance operation. This is done and the thread is secure. However, if a problem occurs during class loading, therefore, it is impossible to use the post to achieve the perfect implementation. We can only choose the appropriate method based on the actual situation.
1. Directly lock the entire object to ensure thread security. However, because the object is locked every time it is obtained, the performance is poor and it is not what we want.
package singlePattern;/** * Thread safe single pattern, but performance is poor, because every time we will lock the instance, * we hope lock the instance on first time but all times * * @author Administrator * */public class SinglePattern { // private instance private static SinglePattern instance = null; // private constructor private SinglePattern() { } // public getInstance method public synchronized static SinglePattern getInstance() { if (instance == null) { instance = new SinglePattern(); } return instance; }}
2. What we need is that synchronization is required during the first initialization, and thread synchronization is not required for subsequent calls. Since the JVM is mutually exclusive when loading classes, we know that the class loader directly executes static variables and static code blocks when loading classes, and then calls common code quickly, then, call the constructor to initialize the heap, and assign a value to the reference in the stack in the returned reference. So we can use static variables and static code blocks loaded by classes to safely construct a singleton instance.
package singlePattern;/** * Thread safe and performance good. * @author Administrator * */public class UserSinglePattern { // private constructor private UserSinglePattern() {} // static inner class, for create a single pattern instance private static class NewInstance { private static UserSinglePattern instance = new UserSinglePattern(); } // the get method for single pattern instance public static UserSinglePattern getInstance() { return NewInstance.instance; }}
I would like to post my reference address to express my gratitude to the author: http://blog.csdn.net/zhangerqing/article/details/8194653