本文主要介紹單例創(chuàng)建的集中方式和反射給單例造成的影響。
單例的定義
單例模式:保證一個類僅有一個實例對象,并且提供一個全局訪問點。
單例的特點
- 單例類只能有一個實例對象
- 單例類必須自己創(chuàng)建自己的唯一實例
- 單例類必須對外提供一個訪問該實例的方法
使用場景及優(yōu)點
優(yōu):
- 提供了對唯一實例的受控訪問
- 保證了內(nèi)存中只有唯一實例,減少內(nèi)存開銷,比如需要多次創(chuàng)建和銷毀實例的場景
- 避免對資源的多重占用,比如文件的寫操作
缺:
- 沒有抽象層,接口,不能繼承,擴展困難,違反了開閉原則
- 單例類一般寫在同一個類中,職責(zé)過重,違背了單一職責(zé)原則
應(yīng)用場景:
文件系統(tǒng);數(shù)據(jù)庫連接池的設(shè)計;日志系統(tǒng)等 IO/生成唯一序列號/身份證/對象需要共享的情況,比如web中配置對象
實現(xiàn)單例
三步:
- 構(gòu)造函數(shù)私有化
- 在類內(nèi)部創(chuàng)建實例
- 提供本類實例的唯一全局訪問點,即唯一實例的方法
餓漢式:
public class Hungry {
// 構(gòu)造器私有,靜止外部new
private Hungry(){}
// 在類的內(nèi)部創(chuàng)建自己的實例
private static Hungry hungry = new Hungry();
// 獲取本類實例的唯一全局訪問點
public static Hungry getHungry(){
return hungry;
}
}
懶漢式:
public class Lazy1 {
// 構(gòu)造器私有,靜止外部new
private Lazy1(){
System.out.println(Thread.currentThread().getName() + " 訪問到了");
}
// 定義即可,不真正創(chuàng)建
private static Lazy1 lazy1 = null;
// 獲取本類實例的唯一全局訪問點
public static Lazy1 getLazy1(){
// 如果實例不存在則new一個新的實例,否則返回現(xiàn)有的實例
if (lazy1 == null) {
lazy1 = new Lazy1();
}
return lazy1;
}
public static void main(String[] args) {
// 多線程訪問,看看會有什么問題
for (int i = 0; i < 10; i++) {
new Thread(()->{
Lazy1.getLazy1();
}).start();
}
}
}
單線程環(huán)境下是沒有問題的,但是多線程的情況下就會出現(xiàn)問題
DCL 懶漢式:
方法上直接加鎖:
public static synchronized Lazy1 getLazy1(){
if (lazy1 == null) {
lazy1 = new Lazy1();
}
return lazy1;
}
縮小鎖范圍:
public static Lazy1 getLazy1(){
if (lazy1 == null) {
synchronized(Lazy1.class){
lazy1 = new Lazy1();
}
}
return lazy1;
}
雙重鎖定:
// 獲取本類實例的唯一全局訪問點
public static Lazy1 getLazy1(){
// 如果實例不存在則new一個新的實例,否則返回現(xiàn)有的實例
if (lazy1 == null) {
// 加鎖
synchronized(Lazy1.class){
// 第二次判斷是否為null
if (lazy1 == null){
lazy1 = new Lazy1();
}
}
}
return lazy1;
}
指令重排序: 指令重排序是JVM為了優(yōu)化指令,提高程序運行效率,在不影響單線程程序執(zhí)行結(jié)果的前提下,盡可能地提高并行度。
首先要知道 lazy1 = new Lazy1(); 這一步并不是一個原子性操作,也就是說這個操作會分成很多步
① 分配對象的內(nèi)存空間 ② 執(zhí)行構(gòu)造函數(shù),初始化對象 ③ 指向?qū)ο蟮絼偡峙涞膬?nèi)存空間
但是 JVM 為了效率對這個步驟進行了重排序,例如這樣:
① 分配對象的內(nèi)存空間 ③ 指向?qū)ο蟮絼偡峙涞膬?nèi)存空間,對象還沒被初始化 ② 執(zhí)行構(gòu)造函數(shù),初始化對象
解決的方法很簡單——在定義時增加 volatile 關(guān)鍵字,避免指令重排
最終代碼:
public class Lazy1 {
// 構(gòu)造器私有,靜止外部new
private Lazy1(){
System.out.println(Thread.currentThread().getName() + " 訪問到了");
}
// 定義即可,不真正創(chuàng)建
private static volatile Lazy1 lazy1 = null;
// 獲取本類實例的唯一全局訪問點
public static Lazy1 getLazy1(){
// 如果實例不存在則new一個新的實例,否則返回現(xiàn)有的實例
if (lazy1 == null) {
// 加鎖
synchronized(Lazy1.class){
// 第二次判斷是否為null
if (lazy1 == null){
lazy1 = new Lazy1();
}
}
}
return lazy1;
}
public static void main(String[] args) {
// 多線程訪問,看看會有什么問題
for (int i = 0; i < 10; i++) {
new Thread(()->{
Lazy1.getLazy1();
}).start();
}
}
}
靜態(tài)內(nèi)部類懶漢式單例:
雙重鎖定算是一種可行不錯的方式,而靜態(tài)內(nèi)部類就是一種更加好的方法,不僅速度較快,還保證了線程安全,先看代碼:
public class Lazy2 {
// 構(gòu)造器私有,靜止外部new
private Lazy2(){
System.out.println(Thread.currentThread().getName() + " 訪問到了");
}
// 用來獲取對象
public static Lazy2 getLazy2(){
return InnerClass.lazy2;
}
// 創(chuàng)建內(nèi)部類
public static class InnerClass {
// 創(chuàng)建單例對象
private static Lazy2 lazy2 = new Lazy2();
}
public static void main(String[] args) {
// 多線程訪問,看看會有什么問題
for (int i = 0; i < 10; i++) {
new Thread(()->{
Lazy2.getLazy2();
}).start();
}
}
}
上面的代碼,首先 InnerClass 是一個內(nèi)部類,其在初始化時是不會被加載的,當(dāng)用戶執(zhí)行了 getLazy2() 方法才會加載,同時創(chuàng)建單例對象,所以他也是懶漢式的方法,因為 InnerClass 是一個靜態(tài)內(nèi)部類,所以只會被實例化一次,從而達到線程安全,因為并沒有加鎖,所以性能上也會很快。
枚舉創(chuàng)建單例:
public enum EnumSingle {
IDEAL;
}
代碼就這樣,簡直不要太簡單,訪問通過 EnumSingle.IDEAL 就可以訪問了
反射破壞單例模式
單例是如何被破壞的:
這是我們原來的寫法,new 兩個實例出來,輸出一下
public class Lazy1 {
// 構(gòu)造器私有,靜止外部new
private Lazy1(){
System.out.println(Thread.currentThread().getName() + " 訪問到了");
}
// 定義即可,不真正創(chuàng)建
private static volatile Lazy1 lazy1 = null;
// 獲取本類實例的唯一全局訪問點
public static Lazy1 getLazy1(){
// 如果實例不存在則new一個新的實例,否則返回現(xiàn)有的實例
if (lazy1 == null) {
// 加鎖
synchronized(Lazy1.class){
// 第二次判斷是否為null
if (lazy1 == null){
lazy1 = new Lazy1();
}
}
}
return lazy1;
}
public static void main(String[] args) {
Lazy1 lazy1 = getLazy1();
Lazy1 lazy2 = getLazy1();
System.out.println(lazy1);
System.out.println(lazy2);
}
}
運行結(jié)果: main 訪問到了 cn.ideal.single.Lazy1@1b6d3586 cn.ideal.single.Lazy1@1b6d3586
可以看到,結(jié)果是單例沒有問題
一個普通實例化,一個反射實例化:
public static void main(String[] args) throws Exception {
Lazy1 lazy1 = getLazy1();
// 獲得其空參構(gòu)造器
Constructor<Lazy1> declaredConstructor = Lazy1.class.getDeclaredConstructor(null);
// 使得可操作性該 declaredConstructor 對象
declaredConstructor.setAccessible(true);
// 反射實例化
Lazy1 lazy2 = declaredConstructor.newInstance();
System.out.println(lazy1);
System.out.println(lazy2);
}
運行結(jié)果:
main 訪問到了 main 訪問到了 cn.ideal.single.Lazy1@1b6d3586 cn.ideal.single.Lazy1@4554617c
可以看到,單例被破壞了
如何解決:因為我們反射走的其無參構(gòu)造,所以在無參構(gòu)造中再次進行非null判斷,加上原來的雙重鎖定,現(xiàn)在也就有三次判斷了。
解決方案:增加一個標(biāo)識位,例如下文通過增加一個布爾類型的 ideal 標(biāo)識,保證只會執(zhí)行一次,更安全的做法,可以進行加密處理,保證其安全性。
這樣就沒問題了嗎,并不是,一旦別人通過一些手段得到了這個標(biāo)識內(nèi)容,那么他就可以通過修改這個標(biāo)識繼續(xù)破壞單例,代碼如下(這個把代碼貼全一點,前面都是節(jié)選關(guān)鍵的,都可以參考這個)
public class Lazy1 {
private static boolean ideal = false;
// 構(gòu)造器私有,靜止外部new
private Lazy1(){
synchronized (Lazy1.class){
if (ideal == false){
ideal = true;
} else {
throw new RuntimeException("反射破壞單例異常");
}
}
System.out.println(Thread.currentThread().getName() + " 訪問到了");
}
// 定義即可,不真正創(chuàng)建
private static volatile Lazy1 lazy1 = null;
// 獲取本類實例的唯一全局訪問點
public static Lazy1 getLazy1(){
// 如果實例不存在則new一個新的實例,否則返回現(xiàn)有的實例
if (lazy1 == null) {
// 加鎖
synchronized(Lazy1.class){
// 第二次判斷是否為null
if (lazy1 == null){
lazy1 = new Lazy1();
}
}
}
return lazy1;
}
public static void main(String[] args) throws Exception {
Field ideal = Lazy1.class.getDeclaredField("ideal");
ideal.setAccessible(true);
// 獲得其空參構(gòu)造器
Constructor<Lazy1> declaredConstructor = Lazy1.class.getDeclaredConstructor(null);
// 使得可操作性該 declaredConstructor 對象
declaredConstructor.setAccessible(true);
// 反射實例化
Lazy1 lazy1 = declaredConstructor.newInstance();
ideal.set(lazy1,false);
Lazy1 lazy2 = declaredConstructor.newInstance();
System.out.println(lazy1);
System.out.println(lazy2);
}
}
運行結(jié)果: main 訪問到了 main 訪問到了 cn.ideal.single.Lazy1@4554617c cn.ideal.single.Lazy1@74a14482 實例化 lazy1 后,其執(zhí)行了修改 ideal 這個布爾值為 false,從而繞過了判斷,再次破壞了單例 所以,可以得出,這幾種方式都是不安全的,都有著被反射破壞的風(fēng)險。