2013-12-18 2 views
2

Я читал раздел ThreadPools раздел 6.2.3 java параллелизм на практике Брайана Гетца. Заявление, с которым я столкнулся, это «Повторное использование существующего потока вместо создания нового, который амортизирует затраты на создание потоков и разрывы».Процесс создания потоков Java

1) Я хотел получить некоторые показатели, связанные с процессом создания потока Java, который, как мы знаем, будет включать создание/распределение стека и регистра счетчика программ в созданный поток. Есть ли инструмент/утилита/визуальный vm tracer/jmx bean, который я могу использовать для того же самого, что может дать мне некоторые индикаторы в памяти и использование времени для создания потоков. Может ли кто-нибудь привести меня к тому же?

2) Есть ли текст, который может привести меня ко всему процессу создания потоков Java в деталях, который должен охватывать соответствующие вызовы ОС Windows?

Why is creating a Thread said to be expensive? дал мне какую-то информацию, но я хотел бы изучить внутренности создания Java нить подробно

Благодаря

+1

Ты смотрел на JConsole, который приходит с распределением из jdk? –

+2

@Shervin - Я посмотрел в jconsole и jvisualvm, так как они поддерживают mbeans, я пошел в ThreadImpl.getThreadAllocatedBytes, это индикатор индикатора размера Java-пакета? Также я не смог найти ни одного индикатора времени, затраченного на создание темы? Также вы могли бы помочь мне по пункту 2, я ищу отличную теорию о процессе построения потоков Java, а соответствующий уровень ОС - для Windows. – 100pipers

ответ

0

Что касается вашего второго вопроса:

2) Есть ли текст который может привести меня ко всему процессу создания темы java , которая должна охватывать соответствующие вызовы ОС для окон?

Это руководство, хоть чуть-чуть не по теме велико: http://blog.jamesdbloom.com/JVMInternals.html

И следующая книга The Java Virtual Machine Specification, Java SE 7 Edition (google book link) объясняет JVM внутренностей в глубине, и как таковой был бы моим лучшим вариант (отказ от ответственности: я только обезжиренного через видимые части)

Если это не достаточно хорошо, вы могли бы всегда download исходный код open jdk (7) и ползать по коду ...

отрывок от открытого кода JDK это (OpenJDK \ точка доступа \ SRC \ доля \ ут \ выполнения \ thread.cpp - c'tor):

// Base class for all threads: VMThread, WatcherThread, ConcurrentMarkSweepThread, 
// JavaThread 


Thread::Thread() { 
    // stack and get_thread 
    set_stack_base(NULL); 
    set_stack_size(0); 
    set_self_raw_id(0); 
    set_lgrp_id(-1); 

    // allocated data structures 
    set_osthread(NULL); 
    set_resource_area(new ResourceArea()); 
    set_handle_area(new HandleArea(NULL)); 
    set_active_handles(NULL); 
    set_free_handle_block(NULL); 
    set_last_handle_mark(NULL); 

    // This initial value ==> never claimed. 
    _oops_do_parity = 0; 

    // the handle mark links itself to last_handle_mark 
    new HandleMark(this); 

    // plain initialization 
    debug_only(_owned_locks = NULL;) 
    debug_only(_allow_allocation_count = 0;) 
    NOT_PRODUCT(_allow_safepoint_count = 0;) 
    NOT_PRODUCT(_skip_gcalot = false;) 
    CHECK_UNHANDLED_OOPS_ONLY(_gc_locked_out_count = 0;) 
    _jvmti_env_iteration_count = 0; 
    set_allocated_bytes(0); 
    _vm_operation_started_count = 0; 
    _vm_operation_completed_count = 0; 
    _current_pending_monitor = NULL; 
    _current_pending_monitor_is_from_java = true; 
    _current_waiting_monitor = NULL; 
    _num_nested_signal = 0; 
    omFreeList = NULL ; 
    omFreeCount = 0 ; 
    omFreeProvision = 32 ; 
    omInUseList = NULL ; 
    omInUseCount = 0 ; 

    _SR_lock = new Monitor(Mutex::suspend_resume, "SR_lock", true); 
    _suspend_flags = 0; 

    // thread-specific hashCode stream generator state - Marsaglia shift-xor form 
    _hashStateX = os::random() ; 
    _hashStateY = 842502087 ; 
    _hashStateZ = 0x8767 ; // (int)(3579807591LL & 0xffff) ; 
    _hashStateW = 273326509 ; 

    _OnTrap = 0 ; 
    _schedctl = NULL ; 
    _Stalled = 0 ; 
    _TypeTag = 0x2BAD ; 

    // Many of the following fields are effectively final - immutable 
    // Note that nascent threads can't use the Native Monitor-Mutex 
    // construct until the _MutexEvent is initialized ... 
    // CONSIDER: instead of using a fixed set of purpose-dedicated ParkEvents 
    // we might instead use a stack of ParkEvents that we could provision on-demand. 
    // The stack would act as a cache to avoid calls to ParkEvent::Allocate() 
    // and ::Release() 
    _ParkEvent = ParkEvent::Allocate (this) ; 
    _SleepEvent = ParkEvent::Allocate (this) ; 
    _MutexEvent = ParkEvent::Allocate (this) ; 
    _MuxEvent = ParkEvent::Allocate (this) ; 

#ifdef CHECK_UNHANDLED_OOPS 
    if (CheckUnhandledOops) { 
    _unhandled_oops = new UnhandledOops(this); 
    } 
#endif // CHECK_UNHANDLED_OOPS 
#ifdef ASSERT 
    if (UseBiasedLocking) { 
    assert((((uintptr_t) this) & (markOopDesc::biased_lock_alignment - 1)) == 0, "forced alignment of thread object failed"); 
    assert(this == _real_malloc_address || 
      this == (void*) align_size_up((intptr_t) _real_malloc_address, markOopDesc::biased_lock_alignment), 
      "bug in forced alignment of thread objects"); 
    } 
#endif /* ASSERT */ 
} 
+1

Я следил за виртуальной машиной Java Биллом Веннерсом, это дает мне понимание внутренних структур данных. Ваш пост выше определенно показывает способ и отлаживает собственные методы, такие как start0() в Thread. Я думаю, это поможет мне понять с точки зрения кода. Благодарю. Хотя найти правильный отладчик. – 100pipers

Смежные вопросы