Design Mode-singleton Mode

Design Mode-singleton Mode
1. The Singleton mode ensures that a class has only one instance and provides a global instance to access it. The essence is to control the number of object instances 2. The Singleton mode is divided into two types: lazy, when the object creates an instance, it will not be created until the instance of the object is used. It is thread unsafe. The Code is as follows: package org. struct; public class Singleton {private static Singleton instance = null; public synchronized static Singleton getInstance () {if (instance = null) {instance = new Singleton ();} return instance;} The Calling method is as follows: ELE. Me, that is, java jvm directly creates an instance when loading the class, which is thread-safe. The lazy code is as follows: package org. struct; public class Singleton {private static Singleton instance = new Singleton (); public static Singleton getInstance () {return instance ;}} The following figure shows the sequence of client calls: in the singleton mode, the implementation of lazy loading reflects the idea of delayed loading. What is delayed loading? It means that data is not loaded when it is not in use. Wait until the resource or data is used immediately. The data must be loaded before it is loaded and becomes Lazy Load, the Code indicating delayed loading is as follows. It is determined only when the instance is used. If the instance has not been created, it will be created immediately. Cache is also a typical solution for exchanging space for time. if (instance = null) {instance = new Singleton ();} 3. Basic Implementation of cache in java. In java code, you can use map to implement caching. The idea is as follows: (1) first go to the cache to find out whether the required resources exist (2). If not found, create a data that meets the requirements and set the data to the cache for future use. The following is a simple example code: package org. struct; import java. util. hashMap; import java. util. map; public class JavaCache {private Map <String, Object> map = new HashMap <String, Object> (); public Object getValue (String key) {Object obj = map. get (key); if (obj = null) {obj = key + ", value"; map. put (key, obj);} return obj;} The Singleton mode is better than package org. struct; public class Singleton {private static class Singlet OnHolder {private static Singleton instance = new Singleton ();} public static Singleton getInstance () {return SingletonHolder (). instance;} When getInstance is called for the first time, it reads SingletonHolder () for the first time (). instance; as a result, the SingletonHolder class is initialized, and its static domain is initialized to create Singleton. Because this is a static domain, it is initialized when the VM loads the class, thread security is the last question of Java virtual machine maintenance. Since the singleton mode controls the number of instances, we have discussed only one instance, can we control the number of instances by ourselves? The answer is yes. Map is also used for implementation. Do you only want to control the number of instances? Others are not considered. The sample code is as follows: package org. struct; import java. util. hashMap; import java. util. map; public class MultInstance {private final static String DEFAULT_KEY = "carche"; private static Map <String, MultInstance> map = new HashMap <String, MultInstance> (); private static int num = 1; private final static int num_max = 3; public static MultInstance getInstane () {String key = DEFAULT_KEY + num; MultInstance m_insInst Ance = map. get (key); if (m_insInstance = null) {m_insInstance = new MultInstance (); map. put (key, m_insInstance);} num ++; if (num> num_max) {num = 1;} return m_insInstance;} public static void main (String [] args) {System. out. println ("-->" + getInstane (); System. out. println ("-->" + getInstane (); System. out. println ("-->" + getInstane (); System. out. println ("-->" + getInstane (); System. out. println ("-->" + GetInstane () ;}} the running result is as follows: --> org. struct. multInstance @ 146ccf3e --> org. struct. multInstance @ 7399f9eb --> org. struct. multInstance @ 1e6ee98 --> org. struct. multInstance @ 146ccf3e --> org. struct. multInstance @ 7399f9eb according to the above running results, there are some shortcomings in the United States: 1. The thread is still insecure. 2. The order of instances generated cannot be guaranteed. 4. Use case when only one instance of a class needs to be controlled and the user can only access it from a global variable, the singleton mode can be considered.