主頁 > 後端開發 > synchronized的實作原理——鎖膨脹程序

synchronized的實作原理——鎖膨脹程序

2020-09-14 03:03:25 後端開發

文章目錄

  • 前言
  • 正文
    • 偏向鎖
    • 輕量鎖
    • 批量重偏向
    • 批量撤銷
    • 重量鎖
  • 總結

前言

上一篇分析了優化后的synchronized在不同場景下物件頭中的表現形式，還記得那個結論嗎？當一個執行緒第一次獲取鎖后再去拿鎖就是偏向鎖，如果有別的執行緒和當前執行緒交替執行就膨脹為輕量級鎖，如果發生競爭就會膨脹為重量級鎖，這句話看起來很簡單，但實際上synhronized的膨脹程序是非常復雜的，有許多場景和細節需要考慮，本篇就對其進行詳細分析，

正文

先來看一個案例代碼：

public class TestInflate {

    static Thread t2;
    static Thread t3;
    static Thread t1;
    static int loopFlag = 19;

    public static void main(String[] args) throws InterruptedException {
        //a 沒有執行緒偏向---匿名    101偏向鎖
        List<A> list = new ArrayList<>();

        t1 = new Thread() {
            @Override
            public void run() {
                for (int i = 0; i < loopFlag; i++) {
                    A a = new A();
                    list.add(a);
                    synchronized (a) {
                        log.debug(i + " " + ClassLayout.parseInstance(a).toPrintableTest(a));
                    }
                }

                log.debug("========t2=================");
                LockSupport.unpark(t2);
            }
        };

        t2 = new Thread() {
            @Override
            public void run() {
                LockSupport.park();
                for (int i = 0; i < loopFlag; i++) {
                    A a = list.get(i);
                    log.debug(i + " " + ClassLayout.parseInstance(a).toPrintable(a));
                    synchronized (a) {
                        log.debug(i + " " + ClassLayout.parseInstance(a).toPrintable(a));
                    }
                    log.debug(i + " " + ClassLayout.parseInstance(a).toPrintable(a));
                }

                log.debug("======t3=====================================");
                LockSupport.unpark(t3);
            }
        };

        t3 = new Thread() {
            @Override
            public void run() {
                LockSupport.park();
                for (int i = 0; i < loopFlag; i++) {
                    A a = list.get(i);
                    log.debug(i + " " + ClassLayout.parseInstance(a).toPrintable(a));
                    synchronized (a) {
                        log.debug(i + " " + ClassLayout.parseInstance(a).toPrintable(a));
                    }
                    log.debug(i + " " + ClassLayout.parseInstance(a).toPrintable(a));
                }
            }
        };

        t1.start();
        t2.start();
        t3.start();
        t3.join();
        log.debug(ClassLayout.parseInstance(new A()).toPrintable());
    }

這里創建了三個執行緒t1、t2、t3，在t1中創建了loopFlag個物件并依次加鎖，然后放入到list中，t2等待t1執行完成后依次讀取list中物件進行加鎖并列印加鎖前、加鎖后、解鎖后的物件頭，t3和t2相同，只不過需要等待t2執行完才開始執行，最后等三個執行緒執行完成后再新建一個物件并列印物件頭（注意運行該代碼需要關閉偏向延遲-XX:BiasedLockingStartupDelay=0），

偏向鎖

偏向鎖沒什么好演示的，但是在原始碼中獲取偏向鎖是第一步，且邏輯比較多，有以下幾點需要注意：

  • 是否已經超過偏向延遲指定的時間，若沒有，則只能獲取輕量鎖
  • 是否允許偏向
  • 如果只有當前執行緒且是第一次則直接獲取偏向鎖（使用class物件中的mark word和執行緒id做"或"操作，得到一個新的header，并通過CAS替換鎖物件頭，替換成功則獲取到偏向鎖，否則進入鎖升級的流程）
  • 是否呼叫了鎖物件未重寫的hashcode（對應原始碼中的Object#hash或System.identityHashCode()方法），hashcode會占用物件頭的空間，導致無法偏向
  • 執行緒是否交替執行（即當前執行緒ID和物件頭中的執行緒ID不一致），若是交替執行可能獲取到偏向鎖、輕量鎖，細節下文詳細講述，

輕量鎖

首先注釋掉t3，先設定loopFlag=19運行t1和t2，你能猜到列印的物件頭是什么樣的么？（為節省篇幅，下文物件頭都只截取最后8位展示）

15:57:38.579 [Thread-0] DEBUG cn.dark.ex6.TestInflate - 0 00000101
15:57:38.580 [Thread-0] DEBUG cn.dark.ex6.TestInflate - 1 00000101
......
15:57:38.582 [Thread-0] DEBUG cn.dark.ex6.TestInflate - 17 00000101
15:57:38.582 [Thread-0] DEBUG cn.dark.ex6.TestInflate - 18 00000101
15:57:38.582 [Thread-0] DEBUG cn.dark.ex6.TestInflate - ========t2=================
15:57:38.582 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 0 00000101
15:57:38.583 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 0 10000000
15:57:38.583 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 0 00000001
15:57:38.583 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 1 00000101
15:57:38.583 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 1 10000000
15:57:38.583 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 1 00000001
......
15:57:38.589 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 17 00000101
15:57:38.589 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 17 10000000
15:57:38.589 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 17 00000001
15:57:38.589 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 18 00000101
15:57:38.590 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 18 10000000
15:57:38.590 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 18 00000001
15:57:38.590 [Thread-1] DEBUG cn.dark.ex6.TestInflate - ======t3=====================================
15:57:38.590 [main] DEBUG cn.dark.ex6.TestInflate - cn.dark.entity.A object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           05 00 00 00 (00000101 00000000 00000000 00000000) (5)
      4     4        (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4        (object header)                           2c 6a 01 f8 (00101100 01101010 00000001 11111000) (-134125012)
     12     4        (loss due to the next object alignment)

t1執行緒不用想，肯定都是101，因為拿到的是偏向鎖，但是t2就和我上一篇說的有點不一樣了，t2加鎖前的狀態和t1解鎖后是一樣的，偏向鎖解鎖不會改變物件頭，接著對其加鎖，判斷當前執行緒id和物件頭中的執行緒id是否相同，由于不相同所以會做偏向撤銷（即將狀態修改為001無鎖狀態）并膨脹為輕量鎖（實際上物件第一次加鎖時，也有這個判斷，接著會判斷是不是匿名偏向，即是不是可偏向模式且第一次加鎖，是則直接獲取偏向鎖），狀態改為00，
需要注意輕量鎖加鎖前會在當前執行緒堆疊幀中創建一個無鎖的Lock Record，加鎖時就會使用CAS操作判斷當前物件頭中的mark word是否和lr中的displaced word相等，由于都是001所以能加鎖成功，之后輕量鎖解鎖只需要將lr中的dr恢復到當前物件頭中（001），這樣下一個執行緒才能對該物件再次加鎖，需要注意雖然輕量鎖解鎖后物件頭是001狀態，但新建的物件依然是默認的101可偏向無鎖狀態，正如上面最后一次列印，

批量重偏向

上面創建的19個物件在膨脹為輕量鎖的時候都會進行偏向撤銷，但是撤銷是有性能損耗的，所以JVM設定了一個閾值，當撤銷達到20次的時候就會進行批量重偏向，該閾值可通過-XX:BiasedLockingBulkRebiasThreshold=20修改，
將上面代碼中的loopFlag改為大于19的數列印結果（后面都不再展示t1執行緒的列印結果）：

16:52:02.005 [Thread-0] DEBUG cn.dark.ex6.TestInflate - ========t2=================
16:52:02.005 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 0 00000101
16:52:02.005 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 0 00110000
16:52:02.005 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 0 00000001
......
16:52:02.011 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 18 00000101
16:52:02.012 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 18 00110000
16:52:02.012 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 18 00000001
16:52:02.012 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 19 00000101
16:52:02.012 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 19 00000101
16:52:02.012 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 19 00000101
16:52:02.012 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 20 00000101
16:52:02.012 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 20 00000101
16:52:02.012 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 20 00000101
16:54:45.035 [main] DEBUG cn.dark.ex6.TestInflate - cn.dark.entity.A object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           05 01 00 00 (00000101 00000001 00000000 00000000) (261)
      4     4        (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4        (object header)                           2c 6a 01 f8 (00101100 01101010 00000001 11111000) (-134125012)
     12     4        (loss due to the next object alignment)

前面19個物件都需要進行撤銷，當達到20時，所有的物件頭都變成了101了，并且偏向當前執行緒t2（這里需要注意，批量指的是當前正被加鎖的所有物件，還沒有加鎖的，即從第21個物件開始都是逐個重偏向；另外雖重偏向是先將鎖物件設定為可偏向無鎖模式101，再講執行緒id設定進去），如果此時你列印完整的物件頭出來還會發現偏向時間戳標志設定為了01，即代表過期進行了重偏向，需要注意，這時候新建的物件也是101狀態，且是重偏向，

批量撤銷

JVM還有一個引數-XX:BiasedLockingBulkRevokeThreshold=40用來控制批量撤銷，即默認當一個類累計撤銷達到40次，那么新建的物件就直接是無鎖不可偏向的，因為JVM認為這是代碼存在了嚴重的問題，
將t3注釋放開，并將loopFlag設定為50，觀察結果：

17:15:46.640 [Thread-1] DEBUG cn.dark.ex6.TestInflate - ======t3=====================================
17:15:46.640 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 0 00000001
17:15:46.640 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 0 11100000
17:15:46.640 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 0 00000001
......
17:15:46.644 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 18 00000001
17:15:46.644 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 18 11100000
17:15:46.644 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 18 00000001
17:15:46.644 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 19 00000101
17:15:46.644 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 19 11100000
17:15:46.644 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 19 00000001
.......
17:15:46.650 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 39 00000101
17:15:46.650 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 39 11100000
17:15:46.651 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 39 00000001
......
17:15:46.652 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 49 00000101
17:15:46.652 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 49 11100000
17:15:46.653 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 49 00000001

 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
      4     4        (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4        (object header)                           2c 6a 01 f8 (00101100 01101010 00000001 11111000) (-134125012)
     12     4        (loss due to the next object alignment)

t3執行緒前面20個物件都是從001加鎖為輕量鎖，所以不用進行撤銷，而t2執行緒從第21個物件開始都是獲取的偏向鎖，所以，t3執行緒就需要從第21個物件開始撤銷，當和其它所有執行緒對該類物件累計撤銷了40次后新建的物件都不能再獲取偏向鎖（這里博主是直接設定的50個物件，讀者可以設定40個物件來驗證），不過在此之前已經獲取偏向鎖的物件還是要逐個撤銷，
但是系統是長期運行的，可能批量重偏向之后很久才會累計撤銷達到40次，比如一個月、一年甚至更久，這種情況下就沒有必要進行批量撤銷了，因此JVM提供了一個引數-XX:BiasedLockingDecayTime=25000，即默認距上一次批量重偏向超過25000ms后，計數器就會重置為0，下面是JVM關于這一點的原始碼：

  // 當前時間
  jlong cur_time = os::javaTimeMillis();
  // 該類上一次批量撤銷的時間
  jlong last_bulk_revocation_time = k->last_biased_lock_bulk_revocation_time();
  // 該類偏向鎖撤銷的次數
  int revocation_count = k->biased_lock_revocation_count();
  // BiasedLockingBulkRebiasThreshold是重偏向閾值（默認20），
  // BiasedLockingBulkRevokeThreshold是批量撤銷閾值（默認40），
  // BiasedLockingDecayTime默認25000，
  if ((revocation_count >= BiasedLockingBulkRebiasThreshold) &&
      (revocation_count <  BiasedLockingBulkRevokeThreshold) &&
      (last_bulk_revocation_time != 0) &&
      (cur_time - last_bulk_revocation_time >= BiasedLockingDecayTime)) {
    // 重置計數器
    k->set_biased_lock_revocation_count(0);
    revocation_count = 0;
  }

具體案例很簡單，讀者們可以思考下怎么驗證這個結論，

重量鎖

由于synchronized是c++語言實作的，實作比較復雜，就不進行詳細的原始碼分析了，下面只是對其實作原理的一個總結，另外重量鎖的實作原理和ReentrantLock的思想是一樣的，讀者們可以對比理解，
當多個執行緒發生競爭的時候，synchronized就會膨脹為重量鎖，這時會創建一個ObjectMoitor物件，這個物件包含了三個由ObjectWaiter物件組成的佇列：cxq、EntryList、WaitSet，以及兩個欄位owner和Read Thread，cxq和EntryList都是獲取鎖失敗用來存盤等待的執行緒的，WaitSet則是Java中呼叫wait方法進入阻塞的執行緒，owner指向當前獲取鎖的執行緒，而Read Thread則表示從cxq和EntryList中挑選出來去搶鎖的執行緒，但由于是非公平鎖，所以不一定能搶到鎖，
在膨脹為重量鎖的時候若沒有獲取到鎖，不是立馬就阻塞未獲取到鎖的執行緒，因其是非公平鎖，首先會去嘗試加鎖，不管前面是否有執行緒等待（如果是公平鎖的話就會判斷是否有執行緒等待，有的話則直接入隊睡眠），如果加鎖失敗，synchronized還會采用自旋的方式去獲取鎖，JDK1.6之前是默認自旋10次后睡眠，而優化之后引入了適應性自旋，即JVM會根據各種情況動態改變自旋次數：

  • 如果平均負載小于CPU則一直自旋
  • 如果有超過(CPU/2)個執行緒正在自旋，則后來執行緒直接阻塞
  • 如果正在自旋的執行緒發現Owner發生了變化則延遲自旋時間（自旋計數）或進入阻塞
  • 如果CPU處于節電模式則停止自旋
  • 自旋時間的最壞情況是CPU的存盤延遲（CPU A存盤了一個資料，到CPU B得知這個資料直接的時間差）
  • 自旋時會適當放棄執行緒優先級之間的差異

你可能會比較好奇為什么不一直采用自旋，因為自旋是會消耗CPU的，適合并發數不多或自旋次數少的情形，否則不如直接呼叫系統函式進入睡眠狀態，
所以當自旋沒有獲取到鎖，則會將當前執行緒添加到cxq佇列的隊首（注意在入隊后還會搶一次鎖，這就是非公平鎖的特點，盡可能的避免呼叫系統函式進入內核態阻塞）并呼叫park函式睡眠，
park函式是基于pthread_mutex_lock函式實作的，而Java中的LockSupport.park則是基于pthread_cond_timedwait函式，這兩個都是系統函式，更底層則是通過futex實作（注意此處都是基于Linux系統討論，其它不同的作業系統有不同的實作方式），這里就不展開討論了，
需要注意執行緒一旦進入佇列后，執行的順序就是固定了，因為在當前持有鎖的執行緒釋放鎖后，會從佇列中喚醒最后入隊的執行緒，即一朝排隊，永遠排隊，所以公平鎖和非公平鎖的區別就體現在入隊前是否搶鎖（排除有新的執行緒來搶鎖的情況），
所謂喚醒最后入隊的執行緒，其實就類似于堆疊，先睡眠的執行緒后喚醒，這點和ReentratLock是相反的，下面給出證明：

public class Demo2 {

    private static Demo2 lock = new Demo2();

    public static void main(String[] args) throws InterruptedException {
        Thread[] threads = new Thread[10];
        for (int i = 0; i < 10; i++) {
            threads[i] = new Thread(() -> {
                synchronized (lock) {
                    log.info(Thread.currentThread().getName());
                }
            });
        }

        synchronized (lock) {
            for (Thread thread : threads) {
                thread.start();
                // 睡眠一下保證執行緒的啟動順序
                Thread.sleep(100);
            }
        }
    }

}

上面程式創建了10個執行緒，然后主執行緒拿到鎖后依次啟動10個執行緒，這10個執行緒內又會分別去獲取鎖，因為被主執行緒占有，就會膨脹為重量鎖進入阻塞，最終列印結果如下：

16:25:49.877 [Thread-9] INFO  cn.dark.mydemo.sync.Demo2 - Thread-9
16:25:49.879 [Thread-8] INFO  cn.dark.mydemo.sync.Demo2 - Thread-8
16:25:49.879 [Thread-7] INFO  cn.dark.mydemo.sync.Demo2 - Thread-7
16:25:49.879 [Thread-6] INFO  cn.dark.mydemo.sync.Demo2 - Thread-6
16:25:49.879 [Thread-5] INFO  cn.dark.mydemo.sync.Demo2 - Thread-5
16:25:49.879 [Thread-4] INFO  cn.dark.mydemo.sync.Demo2 - Thread-4
16:25:49.879 [Thread-3] INFO  cn.dark.mydemo.sync.Demo2 - Thread-3
16:25:49.879 [Thread-2] INFO  cn.dark.mydemo.sync.Demo2 - Thread-2
16:25:49.879 [Thread-1] INFO  cn.dark.mydemo.sync.Demo2 - Thread-1
16:25:49.879 [Thread-0] INFO  cn.dark.mydemo.sync.Demo2 - Thread-0

可以看到10個執行緒并不是按照啟動順序執行的，而是以相反的順序被喚醒并執行，

以上就是Synchronized的膨脹程序以及底層的一些實作原理，最后我畫了一張synchronized鎖膨脹程序的圖幫助理解，有不對的地方歡迎指出：
在這里插入圖片描述

總結

通過兩篇文章分析了synchronized的實作原理，可以看到要實作一把高性能的鎖是相當復雜的，這也是為什么JDK1.6才對synchronized進行了優化（大概也是迫于ReentratLock的壓力吧），優化過后性能基本上和ReentrantLock差不多，只不過后者使用上更加靈活，支持更多的高級特性，但思想上其實都是一樣的（應該都是借鑒了futex的實作原理），
深刻理解synchronized的膨脹程序，不僅僅用于應付面試，而是能夠更好的使用它進行并發編程，比如何時加鎖，何時使用無鎖的自旋鎖，另外在進行業務開發遇到類似場景時也可以借鑒其思想，
本篇文章參考了以下文章，最后在此表示感謝，讓我少走了很多彎路，也了解了很多底層知識，

  • linux內核級同步機制–futex
  • 死磕Synchronized底層實作–偏向鎖
  • 死磕Synchronized底層實作–輕量級鎖
  • 死磕Synchronized底層實作–重量級鎖
  • synchronized實作原理及其優化-（自旋鎖，偏向鎖，輕量鎖，重量鎖）

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/29806.html

標籤：java

上一篇：“史上最全“ Springboot打包war包并部署Linux

下一篇：synchronized批量重偏向與批量撤銷

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C＃(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 【C++】Microsoft C++、C 和匯編程式檔案

    ......

    uj5u.com 2020-09-10 00:57:23 more
  • 例外宣告

    相比于斷言適用于排除邏輯上不可能存在的狀態，例外通常是用于邏輯上可能發生的錯誤。 例外宣告 Item 1：當函式不可能拋出例外或不能接受拋出例外時，使用noexcept 理由 如果不打算拋出例外的話，程式就會認為無法處理這種錯誤，并且應當盡早終止，如此可以有效地阻止例外的傳播與擴散。 示例 //不可 ......

    uj5u.com 2020-09-10 00:57:27 more
  • Codeforces 1400E Clear the Multiset(貪心 + 分治)

    鏈接：https://codeforces.com/problemset/problem/1400/E 來源：Codeforces 思路：給你一個陣列，現在你可以進行兩種操作，操作1：將一段沒有 0 的區間進行減一的操作，操作2：將 i 位置上的元素歸零。最終問：將這個陣列的全部元素歸零后操作的最少 ......

    uj5u.com 2020-09-10 00:57:30 more
  • UVA11610 【Reverse Prime】

    本人看到此題沒有翻譯，就附帶了一個自己的翻譯版本 思考 這一題，它的第一個要求是找出所有 $7$ 位反向質數及其質因數的個數。 我們應該需要質數篩篩選1~$10^{7}$的所有數，這里就不慢慢介紹了。但是，重讀題，我們突然發現反向質數都是 $7$ 位，而將它反過來后的數字卻是 $6$ 位數，這就說明 ......

    uj5u.com 2020-09-10 00:57:36 more
  • 統計區間素數數量

    1 #pragma GCC optimize(2) 2 #include <bits/stdc++.h> 3 using namespace std; 4 bool isprime[1000000010]; 5 vector<int> prime; 6 inline int getlist(int ......

    uj5u.com 2020-09-10 00:57:47 more
  • C/C++編程筆記：C++中的 const 變數詳解，教你正確認識const用法

    1、C中的const 1、區域const變數存放在堆疊區中，會分配記憶體（也就是說可以通過地址間接修改變數的值）。測驗代碼如下： 運行結果： 2、全域const變數存放在只讀資料段（不能通過地址修改，會發生寫入錯誤）， 默認為外部聯編，可以給其他源檔案使用（需要用extern關鍵字修飾） 運行結果： ......

    uj5u.com 2020-09-10 00:58:04 more
  • 【C++犯錯記錄】VS2019 MFC添加資源不懂如何修改資源宏ID

    1. 首先在資源視圖中，添加資源 2. 點擊新添加的資源，復制自動生成的ID 3. 在解決方案資源管理器中找到Resource.h檔案，編輯，使用整個專案搜索和替換的方式快速替換 宏宣告 4. Ctrl+Shift+F 全域搜索，點擊查找全部，然后逐個替換 5. 為什么使用搜索替換而不使用屬性視窗直 ......

    uj5u.com 2020-09-10 00:59:11 more
  • 【C++犯錯記錄】VS2019 MFC不懂的批量添加資源

    1. 打開資源頭檔案Resource.h，在其中預先定義好宏 ID（不清楚其實ID值應該設定多少，可以先新建一個相同的資源項，再在這個資源的ID值的基礎上遞增即可） 2. 在資源視圖中選中專案資源，按F7編輯資源檔案，按 ID 型別 相對路徑的形式添加 資源。（別忘了先把檔案拷貝到專案中的res檔案 ......

    uj5u.com 2020-09-10 01:00:19 more
  • C/C++編程筆記：關于C++的參考型別，專供新手入門使用

    今天要講的是C++中我最喜歡的一個用法——參考，也叫別名。 參考就是給一個變數名取一個變數名，方便我們間接地使用這個變數。我們可以給一個變數創建N個參考，這N + 1個變數共享了同一塊記憶體區域。(參考型別的變數會占用記憶體空間，占用的記憶體空間的大小和指標型別的大小是相同的。雖然參考是一個物件的別名，但 ......

    uj5u.com 2020-09-10 01:00:22 more
  • 【C/C++編程筆記】從頭開始學習C ++：初學者完整指南

    眾所周知，C ++的學習曲線陡峭，但是花時間學習這種語言將為您的職業帶來奇跡，并使您與其他開發人員區分開。您會更輕松地學習新語言，形成真正的解決問題的技能，并在編程的基礎上打下堅實的基礎。 C ++將幫助您養成良好的編程習慣（即清晰一致的編碼風格，在撰寫代碼時注釋代碼，并限制類內部的可見性），并且由 ......

    uj5u.com 2020-09-10 01:00:41 more
最新发布
  • Rust中的智能指標:Box<T> Rc<T> Arc<T> Cell<T> RefCell<T> Weak

    Rust中的智能指標是什么 智能指標（smart pointers）是一類資料結構，是擁有資料所有權和額外功能的指標。是指標的進一步發展 指標（pointer）是一個包含記憶體地址的變數的通用概念。這個地址參考，或 ” 指向”（points at）一些其 他資料 。參考以 & 符號為標志并借用了他們所 ......

    uj5u.com 2023-04-20 07:24:10 more
  • Java的值傳遞和參考傳遞

    值傳遞不會改變本身，參考傳遞（如果傳遞的值需要實體化到堆里）如果發生修改了會改變本身。 1.基本資料型別都是值傳遞 package com.example.basic; public class Test { public static void main(String[] args) { int ......

    uj5u.com 2023-04-20 07:24:04 more
  • [2]SpinalHDL教程——Scala簡單入門

    第一個 Scala 程式 shell里面輸入 $ scala scala> 1 + 1 res0: Int = 2 scala> println("Hello World!") Hello World! 檔案形式 object HelloWorld { /* 這是我的第一個 Scala 程式 * 以 ......

    uj5u.com 2023-04-20 07:23:58 more
  • 理解函式指標和回呼函式

    理解 函式指標 指向函式的指標。比如： 理解函式指標的偽代碼 void (*p)(int type, char *data); // 定義一個函式指標p void func(int type, char *data); // 宣告一個函式func p = func; // 將指標p指向函式func ......

    uj5u.com 2023-04-20 07:23:52 more
  • Django筆記二十五之資料庫函式之日期函式

    本文首發于公眾號：Hunter后端 原文鏈接：Django筆記二十五之資料庫函式之日期函式 日期函式主要介紹兩個大類，Extract() 和 Trunc() Extract() 函式作用是提取日期，比如我們可以提取一個日期欄位的年份，月份，日等資料 Trunc() 的作用則是截取，比如 2022-0 ......

    uj5u.com 2023-04-20 07:23:45 more
  • 一天吃透JVM面試八股文

    什么是JVM？ JVM，全稱Java Virtual Machine（Java虛擬機），是通過在實際的計算機上仿真模擬各種計算機功能來實作的。由一套位元組碼指令集、一組暫存器、一個堆疊、一個垃圾回收堆和一個存盤方法域等組成。JVM屏蔽了與作業系統平臺相關的資訊，使得Java程式只需要生成在Java虛擬機 ......

    uj5u.com 2023-04-20 07:23:31 more
  • 使用Java接入小程式訂閱訊息！

    更新完微信服務號的模板訊息之后，我又趕緊把微信小程式的訂閱訊息給實作了！之前我一直以為微信小程式也是要企業才能申請，沒想到小程式個人就能申請。 訊息推送平臺🔥推送下發【郵件】【短信】【微信服務號】【微信小程式】【企業微信】【釘釘】等訊息型別。 https://gitee.com/zhongfuch ......

    uj5u.com 2023-04-20 07:22:59 more
  • java -- 緩沖流、轉換流、序列化流

    緩沖流 緩沖流, 也叫高效流, 按照資料型別分類： 位元組緩沖流：BufferedInputStream，BufferedOutputStream 字符緩沖流：BufferedReader，BufferedWriter 緩沖流的基本原理，是在創建流物件時，會創建一個內置的默認大小的緩沖區陣列，通過緩沖 ......

    uj5u.com 2023-04-20 07:22:49 more
  • Java-SpringBoot-Range請求頭設定實作視頻分段傳輸

    老實說，人太懶了，現在基本都不喜歡寫筆記了，但是網上有關Range請求頭的文章都太水了 下面是抄的一段StackOverflow的代碼...自己大修改過的，寫的注釋挺全的，應該直接看得懂，就不解釋了 寫的不好...只是希望能給視頻網站開發的新手一點點幫助吧. 業務場景：視頻分段傳輸、視頻多段傳輸（理 ......

    uj5u.com 2023-04-20 07:22:42 more
  • Windows 10開發教程_編程入門自學教程_菜鳥教程-免費教程分享

    教程簡介 Windows 10開發入門教程 - 從簡單的步驟了解Windows 10開發，從基本到高級概念，包括簡介，UWP，第一個應用程式，商店，XAML控制元件，資料系結，XAML性能，自適應設計，自適應UI，自適應代碼，檔案管理，SQLite資料庫，應用程式到應用程式通信，應用程式本地化，應用程式 ......

    uj5u.com 2023-04-20 07:22:35 more

Copyright © 2010-2020 有解無憂