十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
这篇文章主要为大家展示了“Java中单例模式的示例分析”,内容简而易懂,条理清晰,希望能够帮助大家解决疑惑,下面让小编带领大家一起研究并学习一下“Java中单例模式的示例分析”这篇文章吧。
创新互联自2013年起,先为合江等服务建站,合江等地企业,进行企业商务咨询服务。为合江企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。懒汉模式与饿汉模式
懒汉模式就是懒加载,用到的时候去加载,存在线程安全问题,需要手动地加锁控制。它的优点是类加载的速度比较快,按需加载,节省资源。
饿汉模式就是在类加载的时候会创建出实例。它天生就不存在线程安全问题。但是类加载的速度会变慢且耗费资源。
懒汉模式-单重检查
示例代码如下:
public class LazySingleton { private static LazySingleton singletoninstance = null; private Object data = new Object(); //私有化构造方法 private LazySingleton(){ } //加锁访问 public static synchronized LazySingleton getInstance(){ if(singletoninstance == null){ singletoninstance = new LazySingleton(); } return singletoninstance; } public Object getData() { return data; } public void setData(Object data) { this.data = data; } }
测试代码如下:
public class TestThread extends Thread { @Override public void run() { LazySingleton instance = LazySingleton.getInstance(); System.out.println(instance.getData()); } } public static void main(String[] args) { for(int i =0;i < 10;i++){ TestThread t = new TestThread(); t.start(); } } }
运行结果如下:
java.lang.Object@306d3b64
java.lang.Object@306d3b64
java.lang.Object@306d3b64
java.lang.Object@306d3b64
java.lang.Object@306d3b64
java.lang.Object@306d3b64
java.lang.Object@306d3b64
java.lang.Object@306d3b64
java.lang.Object@306d3b64
java.lang.Object@306d3b64
打印出同一个object对象,表明是从同一个LazySingleton对象中获取的数据。
但是上述代码存在一个显著的问题:多个线程同时访问getInstance()方法都是排队式的,即使该instance已经被创建的情况下。然而,如果该instance已经被创建,是可以支持并发访问的。需要对锁的控制细粒度化。
懒汉模式-双重检查
public class LazySingleton { //声明为volatile变量 private static volatile LazySingleton singletoninstance = null; private Object data = new Object(); private LazySingleton(){ } public static synchronized LazySingleton getInstance(){ if(singletoninstance == null){ synchronized (LazySingleton.class) { //这个第二重的的检查是必要的 if(singletoninstance == null) singletoninstance = new LazySingleton(); } } return singletoninstance; } public Object getData() { return data; } public void setData(Object data) { this.data = data; } }
第二重检查是为了防止:
线程A发现instance未被创建,于是申请锁,进入临界区创建instance;于此同时另一个线程也发现instance未被创建,于是也要申请锁去创建instance,问题就这样发生了。而且,这个instance变量要被声明为volatile,也就是其中一个线程对它就行修改之后(也就是实例化),这一修改立马对其他线程可见,避免了无谓的等待。
检查代码同上,运行结果同上。
饿汉模式
public class HungerSingleton { private static final HungerSingleton singletoninstance = new HungerSingleton(); private Object data = new Object(); private HungerSingleton(){ } public static HungerSingleton getInstance(){ return singletoninstance; } public Object getData() { return data; } public void setData(Object data) { this.data = data; } }
在加载该类的时候就立马去实例化instance,不存在线程安全问题(由jvm保证线程安全问题),但是存在资源浪费、加载速度慢的问题。
检查代码同上,运行结果同上。
Holder模式
就是利用一个静态内部类来实现instance的实例化。这里利用了静态内部类的一个特性:该内部类的实例与外部类的实例 没有绑定关系,而且只有被调用到才会装载,从而实现了延迟加载
public class HolderSingleton { private Object data = new Object(); private HolderSingleton(){ } private static class InnerClass{ private static HolderSingleton singletoninstance = new HolderSingleton(); } public static HolderSingleton getInstance(){ return InnerClass.singletoninstance; } public Object getData() { return data; } public void setData(Object data) { this.data = data; } }
测试代码同上,运行结果同上。
在加载InnerClass的时候才会去实例化这个instance,实现了延迟加载,并且同饿汉模式一样,由jvm保证线程安全。这种方法值得推荐。
应用场景:
在整个系统中,只允许共用一个实例的类适合用单例模式来实现,比如:
网站的计数器,只允许存在一个计数器实例;
线程池,只允许存在一个线程池对象;
连接池,只允许存在一个连接池对象;
知识点扩充:
1.为什么要使用单例模式?
在我们日常的工作中,很多对象通常占用非常重要的系统资源,比如:IO处理,数据库操作等,那我们必须要限制这些对象只有且始终使用一个公用的实例,即单例。
2.单例模式的实现方式
构造函数私有化,防止其他类生成唯一公用实例外的实例。且单例类应该被定义为final,也就是说单例类不能被继承,因为如果允许继承那子类就都可以创建实例,违背了类唯一实例的初衷。
类中一个静态变量来保存单实例的引用。
一个共有的静态方法来获取单实例的引用。
3.单例模式的UML类图
4.单例模式的经典实现方式
饿汉式:一开始就创建好实例,每次调用直接返回,经典的“拿空间换时间”。
懒汉式:延迟加载,第一次调用的时候才加载,然后返回,以后的每次的调用就直接返回。经典“拿时间换空间”,多线程环境下要注意解决线程安全的问题。
登记式:对一组单例模式进行的维护,主要是在数量上的扩展,通过线程安全的map把单例存进去,这样在调用时,先判断该单例是否已经创建,是的话直接返回,不是的话创建一个登记到map中,再返回。
以上是“Java中单例模式的示例分析”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注创新互联网站建设公司行业资讯频道!
另外有需要云服务器可以了解下创新互联建站www.cdcxhl.com,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。