成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

源碼分析:Java對象的內存分配

開發 后端
Java對象的分配,根據其過程,將其分為快速分配和慢速分配兩種形式,其中快速分配使用無鎖的指針碰撞技術在新生代的Eden區上進行分配,而慢速分配根據堆的實現方式、GC的實現方式、代的實現方式不同而具有不同的分配調用層次。

Java對象的分配,根據其過程,將其分為快速分配和慢速分配兩種形式,其中快速分配使用無鎖的指針碰撞技術在新生代的Eden區上進行分配,而慢速分配根據堆的實現方式、GC的實現方式、代的實現方式不同而具有不同的分配調用層次。 
下面就以bytecodeInterpreter解釋器對于new指令的解釋出發,分析實例對象的內存分配過程:

一、快速分配

1.實例的創建首先需要知道該類型是否被加載和正確解析,根據字節碼所指定的CONSTANT_Class_info常量池索引,獲取對象的類型信息并調 用is_unresovled_klass()驗證該類是否被解析過,在創建類的實例之前,必須確保該類型已經被正確加載和解析。

  1. CASE(_new): { 
  2.         u2 index = Bytes::get_Java_u2(pc+1); 
  3.         constantPoolOop constants = istate->method()->constants(); 
  4.         if (!constants->tag_at(index).is_unresolved_klass()) { 

2.接下來獲取該類型在虛擬機中的表示instanceKlass(具體可以參考前文實例探索Java對象的組織結構) 

 

  1. oop entry = constants->slot_at(index).get_oop(); 
  2.           assert(entry->is_klass(), "Should be resolved klass"); 
  3.           klassOop k_entry = (klassOop) entry; 
  4.           assert(k_entry->klass_part()->oop_is_instance(), "Should be instanceKlass"); 
  5.           instanceKlass* ik = (instanceKlass*) k_entry->klass_part(); 

3.當類型已經被初始化并且可以被快速分配時,那么將根據UseTLAB來決定是否使用TLAB技術(Thread-Local Allocation Buffers,線程局部分配緩存技術)來將分配工作交由線程自行完成。TLAB是每個線程在Java堆中預先分配了一小塊內存,當有對象創建請求內存分 配時,就會在該塊內存上進行分配,而不需要在Eden區通過同步控制進行內存分配。

 

  1. if ( ik->is_initialized() && ik->can_be_fastpath_allocated() ) { 
  2.             size_t obj_size = ik->size_helper(); 
  3.             oop result = NULL; 
  4.             // If the TLAB isn't pre-zeroed then we'll have to do it 
  5.             bool need_zero = !ZeroTLAB; 
  6.             if (UseTLAB) { 
  7.               result = (oop) THREAD->tlab().allocate(obj_size); 
  8.             } 
  9.             if (result == NULL) { 
  10.               need_zero = true

 

4.如果不使用TLAB或在TLAB上分配失敗,則會嘗試在堆的Eden區上進行分配。Universe::heap()返回虛擬機內存體系所 使用的CollectedHeap,其top_addr()返回的是Eden區空閑塊的起始地址變量_top的地址,end_addr()是Eden區空 閑塊的結束地址變量_end的地址。故這里compare_to是Eden區空閑塊的起始地 址,new_top為使用該塊空閑塊進行分配后新的空閑塊起始地址。這里使用CAS操作進行空閑塊的同步操作,即觀察_top的預期值,若與 compare_to相同,即沒有其他線程操作該變量,則將new_top賦給_top真正成為新的空閑塊起始地址值,這種分配技術叫做bump- the-pointer(指針碰撞技術)。

 

  1. retry: 
  2.               HeapWord* compare_to = *Universe::heap()->top_addr(); 
  3.               HeapWord* new_top = compare_to + obj_size; 
  4.               if (new_top <= *Universe::heap()->end_addr()) { 
  5.                 if (Atomic::cmpxchg_ptr(new_top, Universe::heap()->top_addr(), compare_to) != compare_to) { 
  6.                   goto retry; 
  7.                 } 
  8.                 result = (oop) compare_to; 
  9.               } 
  10.             } 

 

5.根據是否需要填0選項,對分配空間的對象數據區進行填0

  1. if (result != NULL) { 
  2.               // Initialize object (if nonzero size and need) and then the header 
  3.               if (need_zero ) { 
  4.                 HeapWord* to_zero = (HeapWord*) result + sizeof(oopDesc) / oopSize; 
  5.                 obj_size -= sizeof(oopDesc) / oopSize; 
  6.                 if (obj_size > 0 ) { 
  7.                   memset(to_zero, 0, obj_size * HeapWordSize); 
  8.                 } 
  9.               } 

 

6.根據是否使用偏向鎖,設置對象頭信息,然后設置對象的klassOop引用(這樣對象本身就獲取了獲取類型數據的途徑)

 

  1. if (UseBiasedLocking) { 
  2.                 result->set_mark(ik->prototype_header()); 
  3.               } else { 
  4.                 result->set_mark(markOopDesc::prototype()); 
  5.               } 
  6.               result->set_klass_gap(0); 
  7.               result->set_klass(k_entry); 

 

7.把對象地址引入棧,并繼續執行下一個字節碼

  1. SET_STACK_OBJECT(result, 0); 
  2.               UPDATE_PC_AND_TOS_AND_CONTINUE(31); 

8.若該類型沒有被解析,就會調用InterpreterRuntime的_new函數完成慢速分配

  1. // Slow case allocation 
  2.         CALL_VM(InterpreterRuntime::_new(THREAD, METHOD->constants(), index), 
  3.                 handle_exception); 
  4.         SET_STACK_OBJECT(THREAD->vm_result(), 0); 
  5.         THREAD->set_vm_result(NULL); 
  6.         UPDATE_PC_AND_TOS_AND_CONTINUE(31); 

以上就是快速分配的過程,其流程圖如下,關鍵在于快速分配在Eden區所使用的無鎖指針碰撞技術 

    

#p#

二、慢速分配

接下來看看慢速分配是如何進行的: 
1.InterpreterRuntime的_new函數定義在/hotspot/src/share/vm/interpreter/interpreterRuntime.cpp中:

  1. IRT_ENTRY(void, InterpreterRuntime::_new(JavaThread* thread, constantPoolOopDesc* pool, int index)) 
  2.   klassOop k_oop = pool->klass_at(index, CHECK); 
  3.   instanceKlassHandle klass (THREAD, k_oop); 
  4.  
  5.   // Make sure we are not instantiating an abstract klass 
  6.   klass->check_valid_for_instantiation(true, CHECK); 
  7.  
  8.   // Make sure klass is initialized 
  9.   klass->initialize(CHECK); 
  10.  
  11.   oop obj = klass->allocate_instance(CHECK); 
  12.   thread->set_vm_result(obj); 
  13. IRT_END 

  該函數在進行了對象類的檢查(確保不是抽象類)和對該類型進行初始化后,調用instanceKlassHandle的allocate_instance進行內存分配。 
其中instanceKlassHandle類由DEF_KLASS_HANDLE宏進行聲明,注意該類重載了成員訪問運算符”->”,這里的一系列成員方法的訪問實際上是instanceKlass對象的訪問。

 type*    operator -> () const       { return (type*)obj()->klass_part(); }

2.所以實際上是調用了instanceKlass的allocate_instance()成員函數: 
allocate_instance()定義在/hotspot/src/share/vm/oops/instanceKlass.cpp 
(1).檢查是否設置了Finalizer函數,獲取對象所需空間的大小

  1. instanceOop instanceKlass::allocate_instance(TRAPS) { 
  2.      bool has_finalizer_flag = has_finalizer(); // Query before possible GC 
  3.      int size = size_helper();  // Query before forming handle. 

(2).調用CollectedHeap的obj_allocate()創建一個instanceOop(堆上的對象實例),并根據情況注冊Finalizer函數

  1. KlassHandle h_k(THREAD, as_klassOop()); 
  2.  
  3.       instanceOop i; 
  4.  
  5.       i = (instanceOop)CollectedHeap::obj_allocate(h_k, size, CHECK_NULL); 
  6.       if (has_finalizer_flag && !RegisterFinalizersAtInit) { 
  7.         i = register_finalizer(i, CHECK_NULL); 
  8.       } 
  9.       return i; 

3.CollectedHeap::ojb_allocate()定義在/hotspot/src/share/vm/gc_interface/CollectedHeap.hpp中,它將轉而調用內聯函數obj_allocate()

4.obj_allocate()定義在/hotspot/src/share/vm/gc_interface /CollectedHeap.inline.h中,若當正處于gc狀態時,不允許進行內存分配申請,否則將調用 common_mem_allocate_init()進行內存分配并返回獲得內存的起始地址,隨后將調用 post_allocation_setup_obj()進行一些初始化工作 

 

  1. oop CollectedHeap::obj_allocate(KlassHandle klass, int size, TRAPS) { 
  2. //...assert 
  3.   HeapWord* obj = common_mem_allocate_init(size, false, CHECK_NULL); 
  4.   post_allocation_setup_obj(klass, obj, size); 
  5.   NOT_PRODUCT(Universe::heap()->check_for_bad_heap_word_value(obj, size)); 
  6.   return (oop)obj; 

 

5.common_mem_allocate_init()分為兩部分,將分別調用common_mem_allocate_noinit()進行內存空間的分配和調用init_obj()進行對象空間的初始化

  1. HeapWord* CollectedHeap::common_mem_allocate_init(size_t size, bool is_noref, TRAPS) { 
  2.   HeapWord* obj = common_mem_allocate_noinit(size, is_noref, CHECK_NULL); 
  3.   init_obj(obj, size); 
  4.   return obj; 

6.common_mem_allocate_noinit()如下: 
(1).若使用了本地線程分配緩沖TLAB,則會調用allocate_from_tlab()嘗試從TLAB中分配內存

  1. HeapWord* result = NULL; 
  2. if (UseTLAB) { 
  3.   result = CollectedHeap::allocate_from_tlab(THREAD, size); 
  4.   if (result != NULL) { 
  5.     assert(!HAS_PENDING_EXCEPTION, 
  6.            "Unexpected exception, will result in uninitialized storage"); return result; 
  7.   } 
(2).否則會調用堆的mem_allocate()嘗試分配
  1. bool gc_overhead_limit_was_exceeded = false
  2.  result = Universe::heap()->mem_allocate(size, 
  3.                                          is_noref, 
  4.                                          false
  5.                        &gc_overhead_limit_was_exceeded); 

(3).統計分配的字節數

  1. if (result != NULL) { 
  2.   //... 
  3.    THREAD->incr_allocated_bytes(size * HeapWordSize); 
  4.    return result; 
  5.  } 

(4).否則說明申請失敗,若在申請過程中gc沒有超時,則拋出OOM異常

 

  1. if (!gc_overhead_limit_was_exceeded) { 
  2.     // -XX:+HeapDumpOnOutOfMemoryError and -XX:OnOutOfMemoryError support 
  3.     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"); 
  4.     } 
  5.  
  6.     THROW_OOP_0(Universe::out_of_memory_error_java_heap()); 

 

  7.對象內存分配后的初始化過程包括兩部分,一個是init_obj()完成對對象內存空間的對齊和填充,一個是post_allocation_setup_obj()對堆上的oop對象進行初始化。 

  (1).init_obj():

  1. void CollectedHeap::init_obj(HeapWord* obj, size_t size) { 
  2.   assert(obj != NULL, "cannot initialize NULL object"); const size_t hs = oopDesc::header_size(); assert(size >= hs, "unexpected object size"); ((oop)obj)->set_klass_gap(0); Copy::fill_to_aligned_words(obj + hs, size - hs); 
  3. }

  hs就是對象頭的大小,fill_to_aligned_words將對象空間除去對象頭的部分做填0處理,該函數定義在/hotspot /src/share/vm/utilities/copy.h中,并轉而調用pd_fill_to_aligned_words()。 
pd_fill_to_aligned_words根據不同平臺實現,以x86平臺為例,該函數定義在/hotspot/src/cpu/x86/vm/copy_x86.h中:

  1. static void pd_fill_to_words(HeapWord* tohw, size_t count, juint value) { 
  2. #ifdef AMD64 
  3.   julong* to = (julong*) tohw; 
  4.   julong  v  = ((julong) value << 32) | value; 
  5.   while (count-- > 0) { 
  6.     *to++ = v; 
  7.   } 
  8. #else 
  9.   juint* to = (juint*)tohw; 
  10.   count *= HeapWordSize / BytesPerInt; 
  11.   while (count-- > 0) { 
  12.     *to++ = value; 
  13.   } 
  14. #endif // AMD64 

  該函數的作用就是先將地址類型轉換,然后把堆的字數轉化為字節數,再對該段內存進行填值(value = 0)處理

  (2).post_allocation_setup_obj()調用了post_allocation_setup_common()進行初始化工作,然后調用post_allocation_notify()通知JVMTI和dtrace

 

  1. void CollectedHeap::post_allocation_setup_obj(KlassHandle klass, 
  2.                                               HeapWord* obj, 
  3.                                               size_t size) { 
  4.   post_allocation_setup_common(klass, obj, size); 
  5.   assert(Universe::is_bootstrapping() || 
  6.          !((oop)obj)->blueprint()->oop_is_array(), "must not be an array"); // notify jvmti and dtrace   post_allocation_notify(klass, (oop)obj); 

 

post_allocation_setup_common()如下:

 

  1. void CollectedHeap::post_allocation_setup_common(KlassHandle klass, 
  2.                                                  HeapWord* obj, 
  3.                                                  size_t size) { 
  4.   post_allocation_setup_no_klass_install(klass, obj, size); 
  5.   post_allocation_install_obj_klass(klass, oop(obj), (int) size); 

 

post_allocation_setup_no_klass_install()根據是否使用偏向鎖,設置對象頭信息等,即初始化oop的 _mark字段。post_allocation_install_obj_klass()設置對象實例的klassOop引用,即初始化oop的 _metadata(_klass/_compressed_klass)字段 。

以上內容就是堆實現無關的慢速分配過程,其流程圖如下: 

        

三、堆的分配實現

1.mem_allocate將由堆的實現類型定義,以GenCollectedHeap為例:

 

  1. HeapWord* GenCollectedHeap::mem_allocate(size_t size, 
  2.                                          bool is_large_noref, 
  3.                                          bool is_tlab, 
  4.                                          bool* gc_overhead_limit_was_exceeded) { 
  5.   return collector_policy()->mem_allocate_work(size, 
  6.                                                is_tlab, 
  7.                                                gc_overhead_limit_was_exceeded); 

 

2.由之前分析,GenCollectedHeap根據用戶配置有著不同的GC策略(默認的和配置UseSerialGC的 MarkSweepPolicy、配置UseComcMarkSweepGC和UseAdaptiveSizePolicy的 ASConcurrentMarkSweepPolicy、只配置UseComcMarkSweepGC的 ConcurrentMarkSweepPolicy),但這里,對象內存空間的基本結構和分配的思想是一致的,所以統一由 GenCollectorPolicy實現進行分代層級的對象分配操作,但具體的工作將交由各代的實現者來完成。

GenCollectedPolicy的mem_allocate_work()函數如下: 
(1).gch指向GenCollectedHeap堆,內存分配請求將循環不斷地進行嘗試,直到分配成功或GC后分配失敗

  1. HeapWord* GenCollectorPolicy::mem_allocate_work(size_t size, 
  2.                                         bool is_tlab, 
  3.                                         bool* gc_overhead_limit_was_exceeded) { 
  4.   GenCollectedHeap *gch = GenCollectedHeap::heap(); 
  5.   //... 
  6.   // Loop until the allocation is satisified, 
  7.   // or unsatisfied after GC. 
  8.   for (int try_count = 1/* return or throw */; try_count += 1) {  

對于占用空間比較大的對象,如果經常放在新生代,那么剩余的內存空間就會非常緊張,將可能會導致新生代內存垃圾回收的頻繁觸發。故若對象的大小超過一定值,那么就不應該分配在新生代。

 

  1. //...緊接上面部分 
  2. dleMark hm; // discard any handles allocated in each iteration 
  3.  
  4.  // First allocation attempt is lock-free. 
  5.  Generation *gen0 = gch->get_gen(0); 
  6.  
  7.  if (gen0->should_allocate(size, is_tlab)) { 
  8.    result = gen0->par_allocate(size, is_tlab); 
  9.    if (result != NULL) { 
  10.      assert(gch->is_in_reserved(result), "result not in heap"); return result; 
  11.    } 
  12.  } 

 

若對象應該在新生代上分配,就會調用新生代的par_allocate()進行分配,注意在新生代普遍是采用復制收集器的,而內存的分配對應采用了無鎖式的指針碰撞技術。

(2).在新生代上嘗試無鎖式的分配失敗,那么就獲取堆的互斥鎖,并嘗試在各代空間內進行內存分配

 

  1. unsigned int gc_count_before;  // read inside the Heap_lock locked region 
  2.     { 
  3.       MutexLocker ml(Heap_lock); 
  4.      //... 
  5.       bool first_only = ! should_try_older_generation_allocation(size); 
  6.  
  7.       result = gch->attempt_allocation(size, is_tlab, first_only); 
  8.       if (result != NULL) { 
  9.         assert(gch->is_in_reserved(result), "result not in heap"); return result; 
  10.       } 

 

其中should_try_older_generation_allocation()如下:

 

  1. bool GenCollectorPolicy::should_try_older_generation_allocation( 
  2.         size_t word_size) const { 
  3.   GenCollectedHeap* gch = GenCollectedHeap::heap(); 
  4.   size_t gen0_capacity = gch->get_gen(0)->capacity_before_gc(); 
  5.   return    (word_size > heap_word_size(gen0_capacity)) 
  6.          || GC_locker::is_active_and_needs_gc() 
  7.          || gch->incremental_collection_failed(); 

 

當進行gc前,新生代的空閑空間大小不足以分配對象,或者有線程觸發了gc,或前一次的FullGC是由MinorGC觸發的情況,都應該不再嘗試再更高的內存代上進行分配,以保證新分配的對象盡可能在新生代空間上。 

attempt_allocation()實現如下:

 

  1. HeapWord* GenCollectedHeap::attempt_allocation(size_t size, 
  2.                                                bool is_tlab, 
  3.                                                bool first_only) { 
  4.   HeapWord* res; 
  5.   for (int i = 0; i < _n_gens; i++) { 
  6.     if (_gens[i]->should_allocate(size, is_tlab)) { 
  7.       res = _gens[i]->allocate(size, is_tlab); 
  8.       if (res != NULL) return res; 
  9.       else if (first_only) break
  10.     } 
  11.   } 
  12.   // Otherwise... 
  13.   return NULL; 

 

即由低內存代向高內存代嘗試分配內存 

(3).從各個代空間都找不到可用的空閑內存(或不應該在更高的內存代上分配時),如果已經有線程觸發了gc,那么當各代空間還有virtual space可擴展空間可用時,將會嘗試擴展代空間并再次嘗試進行內存分配,有點在gc前想盡一切辦法獲得內存的意思。

 

  1. if (GC_locker::is_active_and_needs_gc()) { 
  2.         if (is_tlab) { 
  3.           return NULL;  // Caller will retry allocating individual object 
  4.         } 
  5.         if (!gch->is_maximal_no_gc()) { 
  6.           // Try and expand heap to satisfy request 
  7.           result = expand_heap_and_allocate(size, is_tlab); 
  8.           // result could be null if we are out of space 
  9.           if (result != NULL) { 
  10.             return result; 
  11.           } 
  12.         } 

 

(4).否則各代已經沒有可用的可擴展空間時,當當前線程沒有位于jni的臨界區時,將釋放堆的互斥鎖,以使得請求gc的線程可以進行gc操作,等待所有本地線程退出臨界區和gc完成后,將繼續循環嘗試進行對象的內存分配

 

  1. JavaThread* jthr = JavaThread::current(); 
  2.         if (!jthr->in_critical()) { 
  3.           MutexUnlocker mul(Heap_lock); 
  4.           // Wait for JNI critical section to be exited 
  5.           GC_locker::stall_until_clear(); 
  6.           continue
  7.         } 

 

(5).若各代無法分配對象的內存,并且沒有gc被觸發,那么當前請求內存分配的線程將發起一次gc,這里將提交給VM一個 GenCollectForAllocation操作以觸發gc,當操作執行成功并返回時,若gc鎖已被獲得,那么說明已經由其他線程觸發了gc,將繼續 循環以等待gc完成

  1. VM_GenCollectForAllocation op(size, 
  2.                                   is_tlab, 
  3.                                   gc_count_before); 
  4.     VMThread::execute(&op); 
  5.     if (op.prologue_succeeded()) { 
  6.       result = op.result(); 
  7.       if (op.gc_locked()) { 
  8.          assert(result == NULL, "must be NULL if gc_locked() is true"); continue// retry and/or stall as necessary 
  9.       } 
否則將等待gc完成,若gc超時則會將gc_overhead_limit_was_exceeded設置為true返回給調用者,并重置超時狀態,并對分配的對象進行填充處理

 

  1. const bool limit_exceeded = size_policy()->gc_overhead_limit_exceeded(); 
  2.   const bool softrefs_clear = all_soft_refs_clear(); 
  3.   assert(!limit_exceeded || softrefs_clear, "Should have been cleared"); 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; 
  4.   } 

 

以上內容就是堆的實現相關、但代/GC實現無關的分配過程,其流程圖歸納如下: 

        

 

責任編輯:王雪燕 來源: 博客園
相關推薦

2018-02-08 14:57:22

對象內存分配

2018-04-08 08:45:53

對象內存策略

2021-02-28 13:22:54

Java內存代碼

2021-03-22 11:51:22

Java內存棧上

2013-11-07 09:42:42

對象對象池加速

2017-02-27 11:48:58

JVM源碼分析Java

2025-04-11 00:44:00

2011-08-16 09:34:34

Nginx

2019-07-29 10:10:06

Java內存線程安全

2023-01-10 09:18:37

Go內存分配逃逸

2021-03-11 08:10:48

JVM對象的創建School

2010-09-25 14:12:50

Java內存分配

2022-11-30 08:19:15

內存分配Go逃逸分析

2009-06-03 15:52:34

堆內存棧內存Java內存分配

2010-09-17 16:14:22

Java內存分配

2023-01-28 08:32:04

Go內存分配

2020-09-25 07:55:51

內存Java對象

2022-12-12 08:42:06

Java對象棧內存

2023-03-26 00:43:42

JVM對象測試

2010-09-25 15:40:52

配置JVM內存
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 精品国产一区二区三区性色av | 成人免费在线视频 | 国产成人99久久亚洲综合精品 | 国产在线观看不卡一区二区三区 | a级黄色毛片免费播放视频 国产精品视频在线观看 | 国产色片| 99在线精品视频 | 羞羞视频在线观看免费观看 | 日本a级大片 | 精品在线免费看 | 91就要激情 | 国产精品久久久久久久久久 | 中文字幕综合 | 97国产超碰| 91欧美精品成人综合在线观看 | 国产在线精品一区二区 | 精品中文字幕在线 | 草久久久| 久久久精品天堂 | 成人久久久 | 先锋资源站 | 国产第一区二区 | 视频一区二区三区中文字幕 | 国产精品久久久久久二区 | 天堂亚洲 | 亚洲精品无 | 成人久久久 | 国产9999精品 | 欧美一区二区三区久久精品 | 蜜臀久久| 成人伊人 | 粉嫩国产精品一区二区在线观看 | 亚洲国产精品久久久 | 久久久综合网 | 国产成人精品一区二区三区在线 | 亚州视频在线 | 中文字幕视频在线观看 | 国产综合精品一区二区三区 | 国产清纯白嫩初高生在线播放视频 | 久久丝袜视频 | 亚洲欧美日韩精品 |