java 实现单例模式

本文深入探讨了单例模式的不同实现方式,包括饿汉式、懒汉式及其在多线程环境下的问题解决策略。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

什么是单例模式呢?百度百科对单例模式做出这样的解释:单例模式是一种常用的软件设计模式。在它的核心结构中只包含一个被称为单例的特殊类。通过单例模式可以保证系统中一个类只有一个实例。即一个类只有一个对象实例。

定义说明了单例模式的重点就是一个类只有一个对象实例,不是2个或多个。在传统的OS(操作系统中),只有单线程,后来为了使多任务能在同一个操作系统中并行运行,引进了多线程的概念。在这里讲述线程是为了接下来更好的介绍单例模式的设计。


单例模式设计一:饿汉式(Lazy loadding) 

public class Singleton {
	
	private Singleton(){ }
	private static final Singleton singleton = new Singleton() ; //注意这里加了final,确保该实例不被jvm回收
	private static Singleton getInstance(){
		return singleton ;
	}
	
}


当系统编译并加载Singleton这个类时(并不是调用),会先执行 private static Singleton singleton = new Singleton() ; 这一句代码,接着执行private Singleton(){ }这一句代码,也就是说只要系统一编译Singleton.java文件时,就会创建Singleton.class的一个实例。其实这是没必要的,换个角度思考一下,我都不需要这个实例,浪费时间不说,还要占用jvm内存。所以说这个类就像一个饿汉,不管如何,有吃的我就吃,吃饱就不管了,一开始就创建一个实例,不管你需不需要,以后就不管了。


单例模式设计二:懒汉式,因为单例模式一中不管该资源(Singleton.class)是否被请求,它都会创建一个对象,占用jvm内存。既然这样,那我们就改进一下吧,所以有了下述代码


public class Singleton {
	
	private Singleton(){ }
	private static Singleton singleton = null  ;
	private static Singleton getInstance(){
		
		if(singleton == null){
			singleton = new Singleton() ;
		}
		return singleton ;
	}
	
}


看起来这段代码是没什么问题,而且还解决了“不管资源是否被请求都会创建一个对象”的情况,但前面笔者曾经提到单线程和多线程。毫无疑问,在单线程下,该代码能正常运行。但是在多线程呢?假如现在有线程A和B,当线程A执行完singleton = new Singleton() ; 这一句代码之后,因为还没来得及和线程B说:"B兄弟,我已经创建了该类的实例,你不需要创建了”。线程B就紧随其后执行了singleton = new Singleton() ;这一句代码,又创建了一个实例。此时就存在了2个实例,此时系统就分不行到底是使用哪个实例了,所以在这种情况下,你的程序就不一定能正常运行了。

单例模式设计三:在单例模式设计二中存在了多线程导致不能是程序正常运行,那么我们就给程序加个锁吧,先让一个线程执行完,再让另一个线程执行。


public class Singleton {
	
	private Singleton(){ }
	private static Singleton singleton = null  ;
	private static synchronized Singleton getInstance(){
		
		if(singleton == null){
			singleton = new Singleton() ;
		}
		return singleton ;
	}
	
}


在Method上加了同步锁时候,可以有效防止得到两个实例的对象。但是每次都要在调用到getInstance()时,都要加个同步锁,执行完之后还要解锁,这无疑有使系统有了额外的开销,还有就是第一次不一定能得到一个实例,可能是两个,这种情况还是和单例模式设计二相似,假入线程A,B在同一时刻调用getInstance()时,系统该给为哪个线程为getInstance()加同步锁呢?或者都不加同步锁,于似乎又出现了两个实例的情况,程序有不能正常运行了。


单例模式设计四:单例模式三加了同步锁之后,虽然在很大程度上避免了两个实例的出现概率,但是给系统加了额外的开销,这无疑还不是一个最好的解决方法。那就劫机者改进代码吧。


public class Singleton {
	
	private Singleton(){ }
	private static Singleton singleton = null  ;
	private static Singleton getInstance(){
		if(singleton == null){     //1
		     synchronized (Singleton.class) {    //2
			singleton = new Singleton() ;   //3
	             }	
	       }
	     return singleton ;
	} 
	
}


这回避免了系统不必要的开销了,只有在调用getInstance()方法且singleton == null 时,才会出现加同步锁和解锁操作,这无疑减少了系统的开销,但是还是避免不了出现两个实例的现象,和单例模式三很相似了.

a:线程A执行到1挂起,线程BA认为singleton为null
b:线程B执行到1挂起,线程B认为singleton为null
c:线程A被唤醒执行synchronized块代码,走完创建了一个对象
d:线程B被唤醒执行synchronized块代码,走完创建了另一个对象


单例模式设计五:单例模式设计四还是避免不了两个实例出现的情况,那我就来个双重检查锁定吧(singleton == null )。

public class Singleton {
	
	private Singleton(){ }
	private static Singleton singleton = null  ;
	private static Singleton getInstance(){
		
		if(singleton == null){    				//1
			synchronized (Singleton.class) {    //2
				if(singleton == null){          //3
				   singleton = new Singleton() ;   //4
				}
			}	
		}
		return singleton ;
	}
	
}


在同步锁代码块内部,再判断一次对象是否为null,为null才创建对象。这种写法已经接近完美:
a:线程A执行到1,已经进入synchronized的时候,线程挂起,线程A占有Singleton.class资源锁;
b:线程B执行到1,当它准备synchronized块时,因为Singleton.class被占用,线程2阻塞;
c:线程A被唤醒,判断出对象为null,执行完创建一个对象
d:线程B被唤醒,判断出对象不为null,不执行创建语句


      如此分析,发现似乎没问题。
      但是实际上并不能保证它在单处理器或多处理器上正确运行;
      问题就出现在singleton = new Singleton()这一行代码。它可以简单的分成如下三个步骤:


      mem= singleton();//1
      instance = mem;//2
constructorSingleton(instance);//3
 这行代码先在内存开辟空间,赋给singleton的引用,然后执行new 初始化数据,但是注意初始化是要消耗时间。如果此时线程C(另一个线程)在执行步骤1的时候,发现singleton 为非null,就直接返回,那么线程C返回的其实是一个没构造完成的对象。
      我们期望1,2,3 按照反序执行,但是实际jvm内存模型,并没有明确的有序指定。
      这归咎于java的平台的内存模型允许“无序写入”。


单例模式设计六:引入volatile关键字,用volatile修饰的变量,线程在每次使用变量的时候,都会读取变量修改后的最的值。volatile很容易被误用,用来进行原子性操作。


public class Singleton {
	
	private Singleton(){ }
	private static volatile Singleton singleton = null  ;
	private static Singleton getInstance(){
		
		if(singleton == null){    				//1
			synchronized (Singleton.class) {    //2
				if(singleton == null){          //3
				singleton = new Singleton() ;   //4
				}
			}	
		}
		return singleton ;
	}
	
}

volatile 变量具有 synchronized 的可见性特性,但是不具备原子特性。这就是说线程能够自动发现 volatile 变量的最新值。

而volatile使用时有明确的规定:
      (1)对变量的写操作不依赖于当前值;
      (2)该变量没有包含在具有其他变量的不变式中;
只有在状态真正独立于程序内其他内容时才能使用 volatile。

读者想了解更多关于volatile关键字的信息,可以参考这篇文章  Java 理论与实践: 正确使用 Volatile 变量


这篇文章时笔者偶尔看到一边博客上详细介绍了单例模式的设计,加上自己的理解而写出来了,略有抄袭的嫌疑,姑且算是原创吧。不过这并不是重点,重点时我们怎么设计这个单例模式。其实作为一名程序员,首先要懂得抄代码(读懂的基础上抄),接下来才是写代码。就好比我们小学学习26个字母拼音时,因为我们读懂了26个字母,渐渐会运用他们(相当于一个抄袭阶段),接下来才是组合拼音形成单词,多个单词练成一片优美的文章(属于写的阶段了)。

写代码也是一样,一样的道理,个人感觉在在知识的世界里不存在无所谓的抄袭。其实写这篇文章主要是想体现我们在做任何是的时候,刚开始提出的方案可能是可行的,但不一定是最优的,经过不断的修改,才有可能使这个方案达到最优(但这也只是可能而已,不一定有最优的,哈哈)重要的是体验这个修改的阶段,弄清修改的原因和目的。从这反射到大学学习上来,刚学习一些课程的时候,因为没有相应的背景知识,所以不想学,当然课程也没学懂,当有一天需要这门课的知识时,我们强迫自己去学习这门课,背景知识没有就自己去网上搜罗,后来才发现这门课的用处体现出来了。在这里,读者想表达的是中国大学的教育应该理论与实践并行发展,不是大学3或4年学习了大量的理论知识,到大三或大四的时候去搞一个毕业实习,让学生体会到:“哇,原来我学到的理论知识能在这里运用,真棒“。虽然亡羊补牢,为时不晚,但是现在物欲横流的社会,大学生能有几个4年一心在学习理论知识,到最后才运用到实践去呢?现在听老师口头上说这门课的知识以后在哪里会用到,我们需要的不是一个口头说说,而是切切实实的学了就要用去实践,在实践中懂得更多。

上面那一段话就当作笔者的牢骚话,不必在意哈。

最后,送给广大读者一句话:”历史没有真正的真相,只有残存的道理“。(这是今天上算法课时马新老师提到的一句话,个人感觉很受用,和这篇文章无关哈)










1. 用户与权限管理模块 角色管理: 学生:查看实验室信息、预约设备、提交耗材申请、参与安全考核 教师:管理课题组预约、审批学生耗材申请、查看本课题组使用记录 管理员:设备全生命周期管理、审核预约、耗材采购与分发、安全检查 用户操作: 登录认证:统一身份认证(对接学号 / 工号系统,模拟实现),支持密码重置 信息管理:学生 / 教师维护个人信息(联系方式、所属院系),管理员管理所有用户 权限控制:不同角色仅可见对应功能(如学生不可删除设备信息) 2. 实验室与设备管理模块 实验室信息管理: 基础信息:实验室编号、名称、位置、容纳人数、开放时间、负责人 功能分类:按学科(计算机实验室 / 电子实验室 / 化学实验室)标记,关联可开展实验类型 状态展示:实时显示当前使用人数、设备运行状态(正常 / 故障) 设备管理: 设备档案:名称、型号、规格、购置日期、单价、生产厂家、存放位置、责任人 全生命周期管理: 入库登记:管理员录入新设备信息,生成唯一资产编号 维护记录:记录维修、校准、保养信息(时间、内容、执行人) 报废处理:登记报废原因、时间,更新设备状态为 "已报废" 设备查询:支持按名称、型号、状态多条件检索,显示设备当前可用情况 3. 预约与使用模块 预约管理: 预约规则:学生可预约未来 7 天内的设备 / 实验室,单次最长 4 小时(可设置) 预约流程:选择实验室→选择设备→选择时间段→提交申请(需填写实验目的) 审核机制:普通实验自动通过,高危实验(如化学实验)需教师审核 使用记录: 签到 / 签退:到达实验室后扫码签到,离开时签退,系统自动记录实际使用时长 使用登记:填写实验内容、设备运行情况(正常 / 异常),异常情况需详细描述 违规管理:迟到 15 分钟自动取消预约,多次违规限制预约权限 4. 耗材与安全管理模块 耗材管理: 耗材档案:名称、规格、数量、存放位置、
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值