一 前期準備

1.1 前置條件

• 集群部署：Kubernetes集群部署參考003——019。
• glusterfs-Kubernetes部署：參考《附010.Kubernetes永久存儲之GlusterFS超融合部署》。

1.2 部署規劃

本實驗使用StatefulSet部署MongoDB集群，同時每個MongoDB實例使用glusterfs實現永久存儲。從而部署無單點故障、高可用、可動態擴展的MongoDB集群。

部署架構如下：

二 創建StatefulSet

2.1 創建storageclass存儲類型

  1 [root@k8smaster01 ~]# vi heketi-secret.yaml			#創建用於保存密碼的secret
  2 apiVersion: v1
  3 kind: Secret
  4 metadata:
  5   name: heketi-secret
  6   namespace: heketi
  7 data:
  8   # base64 encoded password. E.g.: echo -n "mypassword" | base64
  9   key: YWRtaW4xMjM=
 10 type: kubernetes.io/glusterfs

  1 [root@k8smaster01 heketi]# kubectl create -f heketi-secret.yaml	#創建heketi
  2 [root@k8smaster01 heketi]# kubectl get secrets -n heketi
  3 NAME                                 TYPE                                  DATA   AGE
  4 default-token-6n746                  kubernetes.io/service-account-token   3      144m
  5 heketi-config-secret                 Opaque                                3      142m
  6 heketi-secret                        kubernetes.io/glusterfs               1      3m1s
  7 heketi-service-account-token-ljlkb   kubernetes.io/service-account-token   3      143m
  8 [root@k8smaster01 ~]# mkdir mongo
  9 [root@k8smaster01 ~]# cd mongo

  1 [root@k8smaster01 heketi]# vi storageclass-fast.yaml
  2 apiVersion: storage.k8s.io/v1
  3 kind: StorageClass
  4 metadata:
  5   name: fast
  6 parameters:
  7   resturl: "http://10.254.82.26:8080"
  8   clusterid: "d96022e907f82045dcc426a752adc47c"
  9   restauthenabled: "true"
 10   restuser: "admin"
 11   secretName: "heketi-secret"
 12   secretNamespace: "default"
 13   volumetype: "replicate:3"
 14 provisioner: kubernetes.io/glusterfs
 15 reclaimPolicy: Delete

  1 [root@k8smaster01 heketi]# kubectl create -f storageclass-fast.yaml
  2 [root@k8smaster01 heketi]# kubectl get storageclasses/fast

2.2 授權ServiceAccount

本實驗2.4步驟需要使用mongo-sidecar的pod來配置管理mongo pod。

由於默認的service account僅僅只能獲取當前Pod自身的相關屬性，無法觀察到其他名稱空間Pod的相關屬性信息。如果想要擴展Pod，或者一個Pod需要用於管理其他Pod或者是其他資源對象，是無法通過自身的名稱空間的serviceaccount進行獲取其他Pod的相關屬性信息的，因此需要進行手動創建一個serviceaccount，並在創建Pod時進行定義。或者直接將默認的serviceaccount進行授權。

  1 [root@uk8s-m-01 mongo]# vi defaultaccout.yaml
  2 ---
  3 apiVersion: rbac.authorization.k8s.io/v1beta1
  4 kind: ClusterRoleBinding
  5 metadata:
  6   name: DDefault-Cluster-Admin
  7 subjects:
  8   - kind: ServiceAccount
  9     # Reference to upper's `metadata.name`
 10     name: default
 11     # Reference to upper's `metadata.namespace`
 12     namespace: default
 13 roleRef:
 14   kind: ClusterRole
 15   name: cluster-admin
 16   apiGroup: rbac.authorization.k8s.io
 17 
 18 [root@uk8s-m-01 mongo]# kubectl apply -f defaultaccout.yaml

2.3 創建headless Service

  1 [root@k8smaster01 mongo]# vi mongo-headless-service.yaml

略

提示：本實驗直接將headless結合在StatefulSet同一個yaml文件中，參考2.4。

2.4 創建StatefulSet

  1 [root@k8smaster01 mongo]# vi statefulset-mongo.yaml
  2 ---
  3 apiVersion: v1
  4 kind: Service
  5 metadata:
  6   name: mongo
  7   labels:
  8     name: mongo
  9 spec:
 10   ports:
 11   - port: 27017
 12     targetPort: 27017
 13   clusterIP: None
 14   selector:
 15     role: mongo
 16 ---                                  #以上為headless-service
 17 apiVersion: apps/v1beta1
 18 kind: StatefulSet
 19 metadata:
 20   name: mongo
 21 spec:
 22   serviceName: "mongo"
 23   replicas: 3
 24   template:
 25     metadata:
 26       labels:
 27         role: mongo
 28         environment: test
 29     spec:
 30       terminationGracePeriodSeconds: 10
 31       containers:
 32         - name: mongo
 33           image: mongo:3.4             #新版可能不支持smallfiles參數，因此指定為3.4版本
 34           command:
 35             - mongod
 36             - "--replSet"
 37             - rs0
 38             - "--bind_ip"
 39             - 0.0.0.0
 40             - "--smallfiles"           #使用較小的默認文件
 41             - "--noprealloc"           #禁用數據文件預分配
 42           ports:
 43             - containerPort: 27017
 44           volumeMounts:
 45             - name: mongo-persistent-storage
 46               mountPath: /data/db
 47         - name: mongo-sidecar
 48           image: cvallance/mongo-k8s-sidecar
 49           env:
 50             - name: MONGO_SIDECAR_POD_LABELS
 51               value: "role=mongo,environment=test"
 52             - name: KUBERNETES_MONGO_SERVICE_NAME
 53               value: "mongo"
 54   volumeClaimTemplates:
 55   - metadata:
 56       name: mongo-persistent-storage
 57       annotations:
 58         volume.beta.kubernetes.io/storage-class: "fast"
 59     spec:
 60       accessModes: [ "ReadWriteOnce" ]
 61       resources:
 62         requests:
 63           storage: 2Gi

釋義：

1. 該StatefulSet定義了兩個容器：mingo和mongo-sidecar。mongo是主服務程序，mongo-sidecar是將多個mongo實例進行集群設置的工具。同時mongo-sidecar中設置了如下環境變量：

• MONGO_SIDECAR_POD_LABELS：設置為mongo容器的標籤，用於sidecar查詢它所要管理的MongoDB集群實例。
• KUBERNETES_MONGO_SERVICE_NAME：它的值為mongo，表示sidecar將使用mongo這個服務名來完成MongoDB集群的設置。

1. replicas=3表示MongoDB集群由3個mongo實例組成。
2. volumeClaimTemplates是StatefulSet最重要的存儲設置。在annotations段設置volume.beta.kubernetes.io/storage-class=”fast”表示使用名為fast的StorageClass自動為每個mongo Pod實例分配後端存儲。
3. resources.requests.storage=2Gi表示為每個mongo實例都分配2GiB的磁盤空間。

  1 [root@k8smaster01 mongo]# kubectl create -f statefulset-mongo.yaml	#創建mongo

提示：由於國內mongo鏡像可能無法pull，建議通過VPN等方式提前pull鏡像，然後上傳至所有node節點。

  1 [root@VPN ~]# docker pull cvallance/mongo-k8s-sidecar:latest
  2 [root@VPN ~]# docker pull mongo:3.4.4
  3 [root@VPN ~]# docker save -o mongo-k8s-sidecar.tar cvallance/mongo-k8s-sidecar:latest
  4 [root@VPN ~]# docker save -o mongo_3_4_4.tar mongo:3.4.4
  5 [root@k8snode01 ~]# docker load -i mongo-k8s-sidecar.tar
  6 [root@k8snode01 ~]# docker load -i mongo.tar
  7 [root@k8snode01 ~]# docker images

創建異常可通過如下方式刪除，重新創建：

  1 kubectl delete -f statefulset-mongo.yaml
  2 kubectl delete -f mongo-headless-service.yaml
  3 kubectl delete pvc -l role=mongo

三 確認驗證

3.1 查看資源

  1 [root@k8smaster01 mongo]# kubectl get pod -l role=mongo			#查看集群pod
  2 NAME      READY   STATUS    RESTARTS   AGE
  3 mongo-0   2/2     Running   0          9m44s
  4 mongo-1   2/2     Running   0          7m51s
  5 mongo-2   2/2     Running   0          6m1s

StatefulSet會用volumeClaimTemplates中的定義為每個Pod副本都創建一個PVC實例，每個PVC的名稱由StatefulSet定義中volumeClaimTemplates的名稱和Pod副本的名稱組合而成。

  1 [root@k8smaster01 mongo]# kubectl get pvc

  1 [root@k8smaster01 mongo]# kubectl get pods mongo-0 -o yaml | grep -A 3 volumes	#查看掛載

3.2 查看mongo集群

登錄任意一個mongo Pod，在mongo命令行界面用rs.status()命令查看MongoDB集群的狀態，該mongodb集群已由sidecar完成了創建。在集群中包含3個節點 每個節點的名稱都是StatefulSet設置的DNS域名格式的網絡標識名稱：

mongo-0.mongo.default.svc.cluster.local

mongo-1.mongo.default.svc.cluster.local

mongo-2.mongo.default.svc.cluster.local

同時，可以查看每個mongo實例各自的角色（PRIMARY或SECONDARY）。

  1 [root@k8smaster01 mongo]# kubectl exec -ti mongo-0 -- mongo
  2 ……
  3 rs0:PRIMARY> rs.status()

四 集群常見管理

4.1 MongoDB擴容

運行環境過程中，若3個mongo實例不足以滿足業務的要求，可對mongo集群進行擴容。僅需要通過對StatefulSet進行scale操作，從而實現在mongo集群中自動添加新的mongo節點。

  1 [root@k8smaster01 ~]# kubectl scale statefulset mongo --replicas=4	#擴容為4個
  2 [root@k8smaster01 ~]# kubectl get pod -l role=mongo
  3 NAME      READY   STATUS    RESTARTS   AGE
  4 mongo-0   2/2     Running   0          105m
  5 mongo-1   2/2     Running   0          103m
  6 mongo-2   2/2     Running   0          101m
  7 mongo-3   2/2     Running   0          50m

4.2 查看集群成員

  1 [root@k8smaster01 mongo]# kubectl exec -ti mongo-0 -- mongo
  2 ……
  3 rs0:PRIMARY> rs.status()
  4 ……

4.3 故障自動恢復

若在系統運行過程中，某個mongo實例或其所在主機發生故障，則StatefulSet將會自動重建該mongo實例，並保證其身份（ID）和使用的數據（PVC） 不變。以下為mongo-0實例發生故障進行模擬，StatefulSet將會自動重建mongo-0實例，併為其掛載之前分配的PVC“mongo-persistent-storage-mongo-0”。新的服務“mongo-0”在重新啟動后，原數據庫中的數據不會丟失，可繼續使用。

  1 [root@k8smaster01 ~]# kubectl get pvc
  2 [root@k8smaster01 ~]# kubectl delete pod mongo-0
  3 [root@k8smaster01 mongo]# kubectl exec -ti mongo-0 -- mongo
  4 ……
  5 rs0:PRIMARY> rs.status()
  6 ……

提示：進入某個實例查看mongo集群的狀態，mongo-0發生故障前在集群中的角色為PRIMARY，在其脫離集群后，mongo集群會自動選出一個SECONDARY節點提升為PRIMARY節點（本例中為mongo-2）。重啟后的mongo-0則會成為一個新的SECONDARY節點。本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

※不管是台北網頁設計公司、台中網頁設計公司，全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置，台北網頁設計，各種案例分享

前言

這一篇來源我的公眾號，如果你沒看過，正好直接看看，如果看過了也可以再看看，我稍微修改了一些內容，今天講解的內容如下：

 

 

 

 

 

 

 

一、什麼是單例模式

 

【單例模式】，英文名稱：Singleton Pattern，這個模式很簡單，一個類型只需要一個實例，他是屬於創建類型的一種常用的軟件設計模式。通過單例模式的方法創建的類在當前進程中只有一個實例（根據需要，也有可能一個線程中屬於單例，如：僅線程上下文內使用同一個實例）。

1、單例類只能有一個實例。

2、單例類必須自己創建自己的唯一實例。

3、單例類必須給所有其他對象提供這一實例。

 

那咱們大概知道了，其實說白了，就是我們整個項目周期內，只會有一個實例，當項目停止的時候，實例銷毀，當重新啟動的時候，我們的實例又會產品。

上文中說到了一個名詞【創建類型】的設計模式，那什麼是創建類型的設計模式呢？

創建型（Creational）模式：負責對象創建，我們使用這個模式，就是為了創建我們需要的對象實例的。

 

那除了創建型還有其他兩種類型的模式：

結構型（Structural）模式：處理類與對象間的組合

行為型（Behavioral）模式：類與對象交互中的職責分

這兩種設計模式，以後會慢慢說到，這裏先按下不表。

咱們就重點從0開始分析分析如何創建一個單例模式的對象實例。

 

二、如何創建單例模式

 

實現單例模式有很多方法：從“懶漢式”到“餓漢式”，最後“雙檢鎖”模式，這裏咱們就慢慢的，從一步一步的開始講解如何創建單例。

 

1、正常的思考邏輯順序

 

既然要創建單一的實例，那我們首先需要學會如何去創建一個實例，這個很簡單，相信每個人都會創建實例，就比如說這樣的：

/// <summary>
/// 定義一個天氣類
/// </summary>
public class WeatherForecast
{
    public WeatherForecast()
    {
        Date = DateTime.Now;
    }
    public DateTime Date { get; set; }
    public int TemperatureC { get; set; }
    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
    public string Summary { get; set; }
}


 [HttpGet]
 public WeatherForecast Get()
 {
     // 實例化一個對象實例
     WeatherForecast weather = new WeatherForecast();
     return weather;
 }

 

我們每次訪問的時候，時間都是會變化，所以我們的實例也是一直在創建，在變化：

 

 

相信每個人都能看到這個代碼是什麼意思，不多說，直接往下走，我們知道，單例模式的核心目的就是：

必須保證這個實例在整個系統的運行周期內是唯一的，這樣可以保證中間不會出現問題。

 

那好，我們改進改進，不是說要唯一一個么，好說！我直接返回不就行了：

 

 /// <summary>
 /// 定義一個天氣類
 /// </summary>
 public class WeatherForecast
 {
     // 定義一個靜態變量來保存類的唯一實例
     private static WeatherForecast uniqueInstance;

     // 定義私有構造函數，使外界不能創建該類實例
     private WeatherForecast()
     {
         Date = DateTime.Now;
     }
     /// <summary>
     /// 靜態方法，來返回唯一實例
     /// 如果存在，則返回
     /// </summary>
     /// <returns></returns>
     public static WeatherForecast GetInstance()
     {
         // 如果類的實例不存在則創建，否則直接返回
         // 其實嚴格意義上來說，這個不屬於【單例】
         if (uniqueInstance == null)
         {
             uniqueInstance = new WeatherForecast();
         }
         return uniqueInstance;
     }
     public DateTime Date { get; set; }public int TemperatureC { get; set; }
     public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
     public string Summary { get; set; }
 }

 

 

然後我們修改一下調用方法，因為我們的默認構造函數已經私有化了，不允許再創建實例了，所以我們直接這麼調用：

[HttpGet]
 public WeatherForecast Get()
 {
     // 實例化一個對象實例
     WeatherForecast weather = WeatherForecast.GetInstance();
     return weather;
 }

 

最後來看看效果：

 

 

這個時候，我們可以看到，時間已經不發生變化了，也就是說我們的實例是唯一的了，大功告成！是不是很開心！

 

但是，別著急，問題來了，我們目前是單線程的，所以只有一個，那如果多線程呢，如果多個線程同時訪問，會不會也會正常呢？

這裏我們做一個測試，我們在項目啟動的時候，用多線程去調用：

 

 [HttpGet]
 public WeatherForecast Get()
 {
     // 實例化一個對象實例
     //WeatherForecast weather = WeatherForecast.GetInstance();

     // 多線程去調用
     for (int i = 0; i < 3; i++)
     {
         var th = new Thread(
         new ParameterizedThreadStart((state) =>
         {
             WeatherForecast.GetInstance();
         })
         );
         th.Start(i);
     }
     return null;
 }

 

然後我們看看效果是怎樣的，按照我們的思路，應該是只會走一遍構造函數，其實不是：

 

 

 

 

 

 

3個線程在第一次訪問GetInstance方法時，同時判斷(uniqueInstance ==null)這個條件時都返回真，然後都去創建了實例，這個肯定是不對的。那怎麼辦呢，只要讓GetInstance方法只運行一個線程運行就好了，我們可以加一個鎖來控制他，代碼如下：

public class WeatherForecast
{
    // 定義一個靜態變量來保存類的唯一實例
    private static WeatherForecast uniqueInstance;
    // 定義一個鎖，防止多線程
    private static readonly object locker = new object();

    // 定義私有構造函數，使外界不能創建該類實例
    private WeatherForecast()
    {
        Date = DateTime.Now;
    }
    /// <summary>
    /// 靜態方法，來返回唯一實例
    /// 如果存在，則返回
    /// </summary>
    /// <returns></returns>
    public static WeatherForecast GetInstance()
    {
        // 當第一個線程執行的時候，會對locker對象 "加鎖"，
        // 當其他線程執行的時候，會等待 locker 執行完解鎖
        lock (locker)
        {
            // 如果類的實例不存在則創建，否則直接返回
            if (uniqueInstance == null)
            {
                uniqueInstance = new WeatherForecast();
            }
        }

        return uniqueInstance;
    }
    public DateTime Date { get; set; }

    public int TemperatureC { get; set; }

    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);

    public string Summary { get; set; }
}

 

這個時候，我們再併發測試，發現已經都一樣了，這樣就達到了我們想要的效果，但是這樣真的是最完美的么，其實不是的，因為我們加鎖，只是第一次判斷是否為空，如果創建好了以後，以後就不用去管這個 lock 鎖了，我們只關心的是 uniqueInstance 是否為空，那我們再完善一下：

 

/// <summary>
/// 定義一個天氣類
/// </summary>
public class WeatherForecast
{
    // 定義一個靜態變量來保存類的唯一實例
    private static WeatherForecast uniqueInstance;
    // 定義一個鎖，防止多線程
    private static readonly object locker = new object();

    // 定義私有構造函數，使外界不能創建該類實例
    private WeatherForecast()
    {
        Date = DateTime.Now;
    }
    /// <summary>
    /// 靜態方法，來返回唯一實例
    /// 如果存在，則返回
    /// </summary>
    /// <returns></returns>
    public static WeatherForecast GetInstance()
    {
        // 當第一個線程執行的時候，會對locker對象 "加鎖"，
        // 當其他線程執行的時候，會等待 locker 執行完解鎖
        if (uniqueInstance == null)
        {
            lock (locker)
            {
                // 如果類的實例不存在則創建，否則直接返回
                if (uniqueInstance == null)
                {
                    uniqueInstance = new WeatherForecast();
                }
            }
        }

        return uniqueInstance;
    }
    public DateTime Date { get; set; }
    public int TemperatureC { get; set; }
    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
    public string Summary { get; set; }
}

 

這樣才最終的完美實現我們的單例模式！搞定。

 

2、幽靈事件：指令重排

當然，如果你看完了上邊的那四步已經可以出師了，平時我們就是這麼使用的，也是這麼想的，但是真的就是萬無一失么，有一個 JAVA 的朋友提出了這個問題，C# 中我沒有聽說過，是我孤陋寡聞了么：

單例模式的幽靈事件，時令重排會偶爾導致單例模式失效。

 

是不是聽起來感覺很高大上，而不知所云，沒關係，咱們平時用不到，但是可以了解了解：

為何要指令重排？       

指令重排是指的 volatile，現在的CPU一般採用流水線來執行指令。一個指令的執行被分成：取指、譯碼、訪存、執行、寫回、等若干個階段。然後，多條指令可以同時存在於流水線中，同時被執行。
指令流水線並不是串行的，並不會因為一個耗時很長的指令在“執行”階段呆很長時間，而導致後續的指令都卡在“執行”之前的階段上。
相反，流水線是并行的，多個指令可以同時處於同一個階段，只要CPU內部相應的處理部件未被佔滿即可。比如說CPU有一個加法器和一個除法器，那麼一條加法指令和一條除法指令就可能同時處於“執行”階段, 而兩條加法指令在“執行”階段就只能串行工作。
相比於串行+阻塞的方式，流水線像這樣并行的工作，效率是非常高的。

然而，這樣一來，亂序可能就產生了。比如一條加法指令原本出現在一條除法指令的後面，但是由於除法的執行時間很長，在它執行完之前，加法可能先執行完了。再比如兩條訪存指令，可能由於第二條指令命中了cache而導致它先於第一條指令完成。
一般情況下，指令亂序並不是CPU在執行指令之前刻意去調整順序。CPU總是順序的去內存裏面取指令，然後將其順序的放入指令流水線。但是指令執行時的各種條件，指令與指令之間的相互影響，可能導致順序放入流水線的指令，最終亂序執行完成。這就是所謂的“順序流入，亂序流出”。

 

這個是從網上摘錄的，大概意思看看就行,理解雙檢鎖失效原因有兩個重點

1、編譯器的寫操作重排問題.
例 : B b = new B();

上面這一句並不是原子性的操作,一部分是new一個B對象,一部分是將new出來的對象賦值給b.

直覺來說我們可能認為是先構造對象再賦值.但是很遺憾,這個順序並不是固定的.再編譯器的重排作用下,可能會出現先賦值再構造對象的情況.

2、結合上下文,結合使用情景.

理解了1中的寫操作重排以後,我卡住了一下.因為我真不知道這種重排到底會帶來什麼影響.實際上是因為我看代碼看的不夠仔細,沒有意識到使用場景.雙檢鎖的一種常見使用場景就是在單例模式下初始化一個單例並返回,然後調用初始化方法的方法體內使用初始化完成的單例對象.

 

三、Singleton = 單例 ？

 上邊我們說了很多，也介紹了很多單例的原理和步驟，那這裏問題來了，我們在學習依賴注入的時候，用到的 Singleton 的單例注入，是不是和上邊說的一回事兒呢，這裏咱們直接多多線程測試一下就行：

 

/// <summary>
/// 定義一個心情類
/// </summary>
public class Feeling
{
    public Feeling()
    {
        Date = DateTime.Now;
    }
    public DateTime Date { get; set; }
}


 // 單例注入
 services.AddSingleton<Feeling>();


[HttpGet]
public WeatherForecast Get()
{

    // 多線程去調用
    for (int i = 0; i < 3; i++)
    {
        var th = new Thread(
        new ParameterizedThreadStart((state) =>
        {
            //WeatherForecast.GetInstance();
            
            // 此刻的心情
            Feeling feeling = new Feeling();
            Console.WriteLine(feeling.Date);
        })
        );
        th.Start(i);
    }
    return null;
}

 

測試的結果，情理之中，也是意料之外：

 

 

竟然和我們上邊說的是一樣的， 
Singleton是一種懶漢模式 的單例， 因為結論可以看出，有時候我們使用單例模式，並不是寫一個 Sigleton 就能滿足的。    

四、單例模式的優缺點

 

        【優】、單例模式的優點：

             （1）、保證唯一性：防止其他對象實例化，保證實例的唯一性；

             （2）、全局性：定義好數據后，可以再整個項目種的任何地方使用當前實例，以及數據；

        【劣】、單例模式的缺點： 

             （1）、內存常駐：因為單例的生命周期最長，存在整個開發系統內，如果一直添加數據，或者是常駐的話，會造成一定的內存消耗。

 

以下內容來自百度百科：

優點

一、實例控制 單例模式會阻止其他對象實例化其自己的單例對象的副本，從而確保所有對象都訪問唯一實例。
二、靈活性 因為類控制了實例化過程，所以類可以靈活更改實例化過程。  

缺點

一、開銷 雖然數量很少，但如果每次對象請求引用時都要檢查是否存在類的實例，將仍然需要一些開銷。可以通過使用靜態初始化解決此問題。
二、可能的開發混淆 使用單例對象（尤其在類庫中定義的對象）時，開發人員必須記住自己不能使用
new關鍵字實例化對象。因為可能無法訪問庫源代碼，因此應用程序開發人員可能會意外發現自己無法直接實例化此類。
三、對象生存期 不能解決刪除單個對象的問題。在提供內存管理的語言中（例如基於.NET Framework的語言），只有單例類能夠導致實例被取消分配，因為它包含對該實例的私有引用。在某些語言中（如 C++），其他類可以刪除對象實例，但這樣會導致單例類中出現懸浮引用。

 

五、示例代碼

 

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象