2. 程式人生 > >jvm原始碼閱讀筆記[3]：從記憶體分配到觸發GC的細節

jvm原始碼閱讀筆記[3]：從記憶體分配到觸發GC的細節

阿新 • • 發佈：2019-01-02

    
    除了第一篇說到的，對於使用cms回收的應用，會有執行緒輪詢判斷老年代是否滿足GC的條件，若滿足，則會觸發一次cms老年代的回收。
    針對年輕代，更常見的是，執行緒優先在eden區分配物件的時候，若eden區空間不足，則會觸發一次young gc。若不允許擔保失敗，則還可能轉為一次full gc。那麼，今天就來看看這種記憶體分配不足觸發GC的過程。
    以下是collectedHeap.inline.hpp中的分配的程式碼。
    

oop CollectedHeap::obj_allocate(KlassHandle klass, int size, TRAPS) {
  debug_only(check_for_valid_allocation_state());
  assert
 
(!Universe::heap()->is_gc_active(), "Allocation during gc not allowed");//校驗在GC的時候不會進行記憶體分配
  assert(size >= 0, "int won't convert to size_t");
  HeapWord* obj = common_mem_allocate_init(klass, size, CHECK_NULL);
  post_allocation_setup_obj(klass, obj, size);
  NOT_PRODUCT(Universe::heap()->check_for_bad_heap_word_value(obj, size));
  return
 
 (oop)obj;
}

    
    collectedHeap定義了Java堆的實現，定義了堆必須實現的功能，如建立TLAB,記憶體分配等基本功能。然後其他類通過繼承collectedHeap類，實現了幾種具體的堆型別，主要有ParallelScavengeHeap，G1CollectedHeap等。這些細節以後再寫。
    從原始碼中可以看到，首先是一些簡單的校驗，如當前堆不處於GC狀態，分配的大小>0。然後再呼叫common_mem_allocate_init方法進行記憶體分配，再是呼叫post_allocation_setup_obj做一些初始化的工作，如設定物件頭資訊等。
    來看看common_mem_allocate_init方法：
    

HeapWord* CollectedHeap::common_mem_allocate_init(KlassHandle klass, size_t size, TRAPS) {
  HeapWord* obj = common_mem_allocate_noinit(klass, size, CHECK_NULL);
  init_obj(obj, size);//位元組填充和對齊
  return obj;
}

    
    它先是呼叫common_mem_allocate_noinit方法申請了記憶體空間，然後呼叫init_obj方法進行初始化，這裡的初始化主要是為申請出來的這塊空間填充0位元組和位元組對齊。
    還是來看看common_mem_allocate_noinit方法吧。
    


HeapWord* CollectedHeap::common_mem_allocate_noinit(KlassHandle klass, size_t size, TRAPS) {

  CHECK_UNHANDLED_OOPS_ONLY(THREAD->clear_unhandled_oops();)

  if (HAS_PENDING_EXCEPTION) {
    NOT_PRODUCT(guarantee(false, "Should not allocate with exception pending"));
    return NULL;  // caller does a CHECK_0 too
  }

  HeapWord* result = NULL;
  if (UseTLAB) {//在tlab裡分配
    result = allocate_from_tlab(klass, THREAD, size);
    if (result != NULL) {
      assert(!HAS_PENDING_EXCEPTION,
             "Unexpected exception, will result in uninitialized storage");
      return result;
    }
  }
  bool gc_overhead_limit_was_exceeded = false;
   //在堆中分配
  result = Universe::heap()->mem_allocate(size,
                                          &gc_overhead_limit_was_exceeded);
  if (result != NULL) {
    NOT_PRODUCT(Universe::heap()->
      check_for_non_bad_heap_word_value(result, size));
    assert(!HAS_PENDING_EXCEPTION,
           "Unexpected exception, will result in uninitialized storage");
    THREAD->incr_allocated_bytes(size * HeapWordSize);

    AllocTracer::send_allocation_outside_tlab_event(klass, size * HeapWordSize);

    return result;
  }

    //丟擲OOM異常
  if (!gc_overhead_limit_was_exceeded) {
    // -XX:+HeapDumpOnOutOfMemoryError and -XX:OnOutOfMemoryError support
    report_java_out_of_memory("Java heap space");

    if (JvmtiExport::should_post_resource_exhausted()) {
      JvmtiExport::post_resource_exhausted(
        JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP,
        "Java heap space");
    }

    THROW_OOP_0(Universe::out_of_memory_error_java_heap());
  } else {
    // -XX:+HeapDumpOnOutOfMemoryError and -XX:OnOutOfMemoryError support
    report_java_out_of_memory("GC overhead limit exceeded");

    if (JvmtiExport::should_post_resource_exhausted()) {
      JvmtiExport::post_resource_exhausted(
        JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP,
        "GC overhead limit exceeded");
    }

    THROW_OOP_0(Universe::out_of_memory_error_gc_overhead_limit());
  }
}

    
    可以看到分配分為3步，

  1. 若開啟了UseTLAB,則在tlab裡面分配，分配成功則返回物件空間。若分配失敗，則返回null
  2. 若第一步返回的是null,則在堆中進行分配
  3. 若仍分配失敗，則丟擲OOM異常。

    
    先來看看第一個開啟了UseTLAB的情況：
    


HeapWord* CollectedHeap::allocate_from_tlab(KlassHandle klass, Thread* thread, size_t size) {
  assert(UseTLAB, "should use UseTLAB");

  //第一步：直接線上程的tlab上分配，若分配失敗，則走相對慢的分配：allocate_from_tlab_slow
  HeapWord* obj = thread->tlab().allocate(size);
  if (obj != NULL) {
    return obj;
  }
  /* 
  是指當直接線上程的tlab上分配不下的時候，執行緒重新申請一塊tlab,然後在這塊tlab上分配，並返回分配完的地址。
  但如果剩餘的空間>配置的可浪費的空間，則就不在tlab分配，而是去eden區分配
  */
  return allocate_from_tlab_slow(klass, thread, size);
}

    
    首先線上程的tlab上通過指標碰撞分配，若剩餘空間大於要分配的size，則進行分配。若空間不足，則呼叫allocate_from_tlab_slow進行分配。該方法中執行緒重新申請了一塊tlab然後在該tlab上分配。來看看這個方法：
    

HeapWord* CollectedHeap::allocate_from_tlab_slow(KlassHandle klass, Thread* thread, size_t size) {

  /* 
  如果在tlab上的空閒空間大於設定的能忽略的大小，那就不在tlab上分配，而是在堆的共享區域，保留該tlab，用於下次分配使用。
  */
   if (thread->tlab().free() > thread->tlab().refill_waste_limit()) {
    thread->tlab().record_slow_allocation(size);
    return NULL;
  }

  /* 
   忽略此tlab然後重新申請一塊。為了最小化記憶體碎片，最後一個tlab可能比其他的都小
  */
  size_t new_tlab_size = thread->tlab().compute_size(size);

  thread->tlab().clear_before_allocation();

  if (new_tlab_size == 0) {
    return NULL;
  }

  // 申請一個新的tlab
  HeapWord* obj = Universe::heap()->allocate_new_tlab(new_tlab_size);
  if (obj == NULL) {
    return NULL;
  }

  AllocTracer::send_allocation_in_new_tlab_event(klass, new_tlab_size * HeapWordSize, size * HeapWordSize);

  if (ZeroTLAB) {
    Copy::zero_to_words(obj, new_tlab_size);
  } else {
#ifdef ASSERT
    size_t hdr_size = oopDesc::header_size();
    Copy::fill_to_words(obj + hdr_size, new_tlab_size - hdr_size, badHeapWordVal);
#endif // ASSERT
  }
  thread->tlab().fill(obj, obj + size, new_tlab_size);
  return obj;
}

    
    可以看到，當tlab中剩餘空間>設定的可忽略大小以及申請一塊新的tlab失敗時返回null,然後走上面的第二步，也就是在堆的共享區域分配。當tlab剩餘空間可以忽略，則申請一塊新的tlab，若申請成功，則在此tlab上分配。
    再來看看分配的幾個步驟

  1. 若開啟了UseTLAB,則在tlab裡面分配，分配成功則返回物件空間。若分配失敗，則返回null
  2. 若第一步返回的是null,則在堆中進行分配
  3. 若仍分配失敗，則丟擲OOM異常。

    總結起來第一步就是：若開啟了tlab,則先通過指標碰撞線上程的tlab分配。若在當前執行緒的tlab分配不下，則判斷tlab剩餘空間能否忽略。若能忽略，則忽略此tlab然後重新申請一塊tlab。若不能忽略，或者申請tlab失敗，則返回null。若申請了tlab後分配成功，則返回分配完的空間。若返回的是null,則接下來需要在堆的共享區域內分配（tlab雖然也在堆中，但是執行緒各自的，並不是共享的）。

    接下來我們看看第二步:在堆中進行分配。主要是mem_allocate方法。
    


HeapWord* GenCollectorPolicy::mem_allocate_work(size_t size,
                                        bool is_tlab,
                                        bool* gc_overhead_limit_was_exceeded) {
  GenCollectedHeap *gch = GenCollectedHeap::heap();

  debug_only(gch->check_for_valid_allocation_state());
  assert(gch->no_gc_in_progress(), "Allocation during gc not allowed");

  /* 
   一般來說，gc_overhead_limit_was_exceeded=false。
   只有當gc 時間限制超過了下面的檢查時才會設定成true.
  */
   *gc_overhead_limit_was_exceeded = false;

  HeapWord* result = NULL;


   for (int try_count = 1, gclocker_stalled_count = 0; /* return or throw */; try_count += 1) {
    HandleMark hm; 

    // .第一次嘗試分配不需要獲取鎖，通過while+CAS來保障
    Generation *gen0 = gch->get_gen(0);//年輕代
    assert(gen0->supports_inline_contig_alloc(),
      "Otherwise, must do alloc within heap lock");
    if (gen0->should_allocate(size, is_tlab)) {//對大小進行判斷，比如是否超過eden區能分配的最大大小
      result = gen0->par_allocate(size, is_tlab);//while迴圈+指標碰撞+CAS分配，
      if (result != NULL) {
        assert(gch->is_in_reserved(result), "result not in heap");
        return result;
      }
    }

    //如果res=null,表示在eden區分配失敗了，因為沒有連續的空間。則繼續往下走
    unsigned int gc_count_before;  
    {
      MutexLocker ml(Heap_lock);//獲取鎖
      if (PrintGC && Verbose) {
        gclog_or_tty->print_cr("TwoGenerationCollectorPolicy::mem_allocate_work:"
                      " attempting locked slow path allocation");
      }
      //需要注意的是，只有大物件可以被分配在老年代。一般情況下都是false,所以first_only=true
      bool first_only = ! should_try_older_generation_allocation(size);

      result = gch->attempt_allocation(size, is_tlab, first_only);//在每個代嘗試分配，first_only=true時只會在年輕代分配
      if (result != NULL) {
        assert(gch->is_in_reserved(result), "result not in heap");
        return result;
      }
      /*Gc操作已被觸發但還無法被執行,一般不會出現這種情況，只有在jni中jni_GetStringCritical等方法被呼叫時出現is_active_and_needs_gc=TRUE，主要是為了避免GC導致物件地址改變。jni_GetStringCritical方法的作用參考文章：http://blog.csdn.net/xyang81/article/details/42066665
      */
      if (GC_locker::is_active_and_needs_gc()) {  
        if (is_tlab) {
          return NULL;  // Caller will retry allocating individual object
        }
        if (!gch->is_maximal_no_gc()) {//因為不能進行GC回收，所以只能嘗試通過擴堆

          result = expand_heap_and_allocate(size, is_tlab);
          if (result != NULL) {
            return result;
          }
        }

        /*
        Number of times to retry allocations when "                      \
          "blocked by the GC locker
         GCLockerRetryAllocationCount 預設值=2
        */
        if (gclocker_stalled_count > GCLockerRetryAllocationCount) {
          return NULL; // we didn't get to do a GC and we didn't get any memory
        }


        JavaThread* jthr = JavaThread::current();
        if (!jthr->in_critical()) {
          MutexUnlocker mul(Heap_lock);
          // Wait for JNI critical section to be exited
          GC_locker::stall_until_clear();
          gclocker_stalled_count += 1;
          continue;
        } else {
          if (CheckJNICalls) {
            fatal("Possible deadlock due to allocating while"
                  " in jni critical section");
          }
          return NULL;
        }
      }

      gc_count_before = Universe::heap()->total_collections();
    }

    VM_GenCollectForAllocation op(size, is_tlab, gc_count_before);//VM操作進行一次由分配失敗觸發的GC
    VMThread::execute(&op);
    if (op.prologue_succeeded()) { //一次GC操作已完成  
      result = op.result();
      if (op.gc_locked()) {//當前執行緒沒有成功觸發GC(可能剛被其它執行緒觸發了),則繼續重試分配  
         assert(result == NULL, "must be NULL if gc_locked() is true");
         continue;  // retry and/or stall as necessary 重試分配
      }

      /* 
      分配失敗且已經完成GC了，則判斷是否超時等資訊。
       */
      const bool limit_exceeded = size_policy()->gc_overhead_limit_exceeded();
      const bool softrefs_clear = all_soft_refs_clear();

      if (limit_exceeded && softrefs_clear) {
        *gc_overhead_limit_was_exceeded = true;
        size_policy()->set_gc_overhead_limit_exceeded(false);
        if (op.result() != NULL) {
          CollectedHeap::fill_with_object(op.result(), size);
        }
        return NULL;
      }
      assert(result == NULL || gch->is_in_reserved(result),
             "result not in heap");
      return result;
    }

    // Give a warning if we seem to be looping forever.
    if ((QueuedAllocationWarningCount > 0) &&
        (try_count % QueuedAllocationWarningCount == 0)) {
          warning("TwoGenerationCollectorPolicy::mem_allocate_work retries %d times \n\t"
                  " size=" SIZE_FORMAT " %s", try_count, size, is_tlab ? "(TLAB)" : "");
    }
  }
  //for迴圈結束
}

    
    該方法比較長，主要分為以下幾步：
    1.先判斷是否在年輕代設定了最大能分配的大小。若沒設定（預設沒設定）或者此處分配的大小<設定的最大能分配的大小，則通過while+CAS的方式無鎖在eden區分配。否則，進入第二步的分配
    2.先獲取堆鎖，然後判斷此次分配能否在old區分配。接下來，根據判斷的結果在堆的年輕代和老年代分配。
    3.如果第二步分配失敗，判斷此時有沒有jni_GetStringCritical等JNI方法被呼叫。若有JNI呼叫，因為無法GC（可參考http://blog.csdn.net/xyang81/article/details/42066665），所以只能判斷能否擴堆。若能擴堆則擴堆。若不能擴堆，因為最外層是for迴圈，則跳過此處迴圈進行下次迴圈。
    4.若3仍然失敗了，則通過VM觸發一次由分配失敗觸發的一次GC，也就是我們經常能在GC日誌裡面看到的“_allocation_failure”。具體VM觸發的GC的細節下篇文章再做具體的描述。

    來看看第2步中JVM是怎麼判斷物件能否在Old區分配的：
    

bool GenCollectorPolicy::should_try_older_generation_allocation(
        size_t word_size) const {
  GenCollectedHeap* gch = GenCollectedHeap::heap();
  size_t gen0_capacity = gch->get_gen(0)->capacity_before_gc();//eden大小+from大小
  return    (word_size > heap_word_size(gen0_capacity))
         || GC_locker::is_active_and_needs_gc()
         || gch->incremental_collection_failed();
}

    
    只要以下3個條件滿足一個，就可以在old區分配物件:

  1. 要分配的大小>年輕代容量（eden+from總大小）
  2. 某些JNI方法正在被呼叫
  3. 最近發生過一次擔保失敗或者可能發生擔保失敗

    總結起來，分配分為3個大步驟：

  1. 若開啟了UseTLAB,則在tlab裡面分配，分配成功則返回物件空間。若分配失敗，則返回null
  2. 若第一步返回的是null,則在堆中進行分配
  3. 若仍分配失敗，則丟擲OOM異常。

    具體細節來講，第一步做的是：若開啟了tlab,則先通過指標碰撞線上程的tlab分配。若在當前執行緒的tlab分配不下，則判斷tlab剩餘空間能否忽略。若能忽略，則忽略此tlab然後重新申請一塊tlab。若不能忽略，或者申請tlab失敗，則返回null。若申請了tlab後分配成功，則返回分配完的空間。若返回的是null,則接下來需要在堆的共享區域內分配（tlab雖然也在堆中，但是執行緒各自的，並不是共享的）。
    第二步具體的是：
    1.先判斷是否在年輕代設定了最大能分配的大小。若沒設定（預設沒設定）或者此處分配的大小<設定的最大能分配的大小，則通過while+CAS的方式無鎖在eden區分配。否則，進入第二步的分配
    2.先獲取堆鎖，然後判斷此次分配能否在old區分配。接下來，根據判斷的結果在堆的年輕代和老年代分配。
    3.如果第二步分配失敗，判斷此時有沒有jni_GetStringCritical等JNI方法被呼叫。若有JNI呼叫，因為無法GC，所以只能判斷能否擴堆。若能擴堆則擴堆。若不能擴堆，因為最外層是for迴圈，則跳過此處迴圈進行下次迴圈。
    4.若3仍然失敗了，則通過VM觸發一次由分配失敗觸發的一次GC，也就是我們經常能在GC日誌裡面看到的“_allocation_failure”。

相關推薦

jvm原始碼閱讀筆記[3]：從記憶體分配到觸發GC的細節

         除了第一篇說到的，對於使用cms回收的應用，會有執行緒輪詢判斷老年代是否滿足GC的條件，若滿足，則會觸發一次cms老年代的回收。     針對年輕代，更常見的是，執行緒優先在eden區分配物件的時候，若eden區空間不足，則會觸發一次y

jvm原始碼閱讀筆記[5]：記憶體分配失敗觸發的GC究竟對記憶體做了什麼？

         在第3篇文章中，我們總結到，當分配記憶體失敗時，會通過VM觸發一次由分配失敗觸發的一次GC，也就是我們經常能在GC日誌裡面看到的“allocation failure” VM_GenCollectForAllocation op(s

jvm原始碼閱讀筆記[7]-從jstat -gccause命令談到jvm中都有哪些GC cause

         大家都知道，當我們使用以下命令時，會打印出導致GC的原因 jstat -gccause pid 1000               可以看到最後2列分別列出了上次GC的原因和當前GC的原因。有一個”Heap Inspec

Spring原始碼閱讀筆記(二)：ApplicationContext初始化簡要流程

基於Spring框架的應用，最主要的亮點就是bean的IoC。而IoC容器的配置、組裝由ApplicationContext完成，那麼我們就從這裡開始，去探究IoC如何管理到bean物件。 ApplicationContext初始化簡要流程 Spring

JVM筆記4：Java記憶體分配策略及配置引數

簡單來說，物件記憶體分配主要是在堆中分配。但是分配的規則並不是固定的，取決於使用的收集器組合以及JVM記憶體相關引數的設定 以下介紹幾條基本規則（使用的ParNew+Serial Old收集器組合）： 一，物件優先在新生代Eden區分配 //-XX:+UseParNew

jvm原始碼閱讀筆記[6]-雜談JIT中對Exception做的優化

public class NpeThief { public void callManyNPEInLoop() { for (int i = 0; i &lt; 10

vnpy原始碼閱讀學習(3)：學習vnpy的介面的實現

學習vnpy的介面的實現 通過簡單的學習了PyQt5的一些程式碼以後，我們基本上可以理解PyQt的一些用法，下面讓我們來先研究下vnpy的UI部分的程式碼。 首先回到上一節看到的run.py(/vnpy/example/trade/run.py)的關於UI部分的程式碼。 生成QApplication部分 qa

Spring原始碼閱讀筆記03：xml配置讀取

　　前面的文章介紹了IOC的概念，Spring提供的bean容器即是對這一思想的具體實現，在接下來的幾篇文章會側重於探究這一bean容器是如何實現的。在此之前，先用一段話概括一下bean容器的基本工作原理。顧名思義，bean容器的作用是替我們管理bean物件(簡單的Java類物件)的。不管框架如何強大，還是需

Spring原始碼閱讀筆記05：自定義xml標籤解析

　　在上篇文章中，提到了在Spring中存在預設標籤與自定義標籤兩種，並且詳細分析了預設標籤的解析，本文就來分析自定義標籤的解析，像Spring中的AOP就是通過自定義標籤來進行配置的，這裡也是為後面學習AOP原理打下基礎。 　　這裡先回顧一下，當Spring完成了從配置檔案到Document的轉換並提取對應

spring原始碼閱讀筆記06：bean載入之準備建立bean

　　上文中我們學習了bean載入的整個過程，我們知道從spring容器中獲取單例bean時會先從快取嘗試獲取，如果快取中不存在已經載入的單例bean就需要從頭開始bean的建立，而bean的建立過程是非常複雜的，本文就開始研究bean載入這部分的原始碼。 1. bean建立流程分析 　　在Spring中bea

spring原始碼閱讀筆記09：迴圈依賴

　　前面的文章一直在研究Spring建立Bean的整個過程，建立一個bean是一個非常複雜的過程，而其中最難以理解的就是對迴圈依賴的處理，本文就來研究一下spring是如何處理迴圈依賴的。   1. 什麼是迴圈依賴   不管之前是否研究過迴圈依賴，這裡先對這個知識做一點回顧。   迴圈依賴就是迴圈引

spring原始碼閱讀筆記10：bean生命週期

　　前面的文章主要集中在分析Spring IOC容器部分的原理，這部分的核心邏輯是和bean建立及管理相關，對於單例bean的管理，從建立好到快取起來再到銷燬，其是有一個完整的生命週期，並且Spring也在整個bean的建立過程中提供了多處介面供使用者自己擴充套件，本文就來梳理一下Spring中的bean生命

《機器學習實戰》第2章閱讀筆記3 使用K近鄰演算法改進約會網站的配對效果—分步驟詳細講解1——資料準備：從文字檔案中解析資料（附詳細程式碼及註釋）

 本篇使用的資料存放在文字檔案datingTestSet2.txt中，每個樣本資料佔據一行，總共有1000行。 樣本主要包含以下3中特徵： （1）每年獲得飛行常客里程數 （2）玩視訊遊戲所耗時間百分比 （3）每週消費的冰淇淋公升數 在使用分類器之前，需要將處理的檔案格式

20171104-構建之法：現代軟件工程-閱讀筆記3

叠代 進行 read 大項目 一個 獨立 子項目 運行 目的 本周閱讀了《構建之法》第六章。 第六章講了敏捷流程的相關知識 看了第六章了解到敏捷開發以用戶的需求進化為核心，采用叠代、循序漸進的方法進行軟件開發。在敏捷開發中，軟件項目在構建初期被切分成多個子項目，各個子項目的

JVM系列第4講：從原始碼到機器碼，發生了什麼？

在上篇文章我們聊到，無論什麼語言寫的程式碼，其到最後都是通過機器碼執行的，無一例外。那麼對於 Java 語言來說，其從原始碼到機器碼，這中間到底發生了什麼呢？這就是今天我們要聊的。 如下圖所示，編譯器可以分為：前端編譯器、JIT 編譯器和AOT編譯器。下面我們逐個講解。 前端編譯器：原始碼到位元組碼

Tensorflow object detection API 原始碼閱讀筆記：RPN

Update: 建議先看從程式設計實現角度學習Faster R-CNN，比較直觀。這裡由於原始碼抽象程度較高，顯得比較混亂。 faster_rcnn_meta_arch.py中這兩個對應知乎文章中RPN包含的3*3和1*1卷積： rpn_box_pred

Tensorflow object detection API 原始碼閱讀筆記：架構

在之前的博文中介紹過用tf提供的預訓練模型進行inference，非常簡單。這裡我們深入原始碼，瞭解檢測API的程式碼架構，每個部分的深入閱讀留待後續。 '''構建自己模型的介面是虛基類DetectionModel，具體有5個抽象函式需要實現。 ''' o

Tensorflow object detection API 原始碼閱讀筆記：RFCN

有了前面Faster R-CNN的基礎，RFCN就比較容易了。 """object_detection/meta_architectures/rfcn_meta_arch.py The R-FCN

JVM學習筆記3：GC日誌和常用命令工具

文檔 排除 for 深入理解 ren read tid 虛擬機 int 本篇是系列的第三篇，本篇會簡單介紹GC日誌如何查看以及常用的命令行工具使用方法。其實Java性能診斷和故障排除可以更多地使用阿裏開源的arthas：https://github.com/alibaba/

Vue2.0原始碼閱讀筆記（四）：nextTick

  在閱讀 nextTick 的原始碼之前，要先弄明白 JS 執行環境執行機制，介紹 JS 執行環境的事件迴圈機制的文章很多，大部分都闡述的比較籠統，甚至有些文章說的是錯誤的，以下為個人理解，如有錯誤，歡迎指正。 一、瀏覽器中的程序與執行緒   以 chorme 瀏覽器為例，瀏覽器中的每個頁面都是一個獨立的程