safepoint是什么

java程序里面有很多很多的java線程，每個(gè)java線程又有自己的stack，并且共享了heap。這些線程一直運(yùn)行呀運(yùn)行，不斷對(duì)stack和heap進(jìn)行操作。

這個(gè)時(shí)候如果JVM需要對(duì)stack和heap做一些操作該怎么辦呢？

比如JVM要進(jìn)行GC操作，或者要做heap dump等等，這時(shí)候如果線程都在對(duì)stack或者h(yuǎn)eap進(jìn)行修改，那么將不是一個(gè)穩(wěn)定的狀態(tài)。GC直接在這種情況下操作stack或者h(yuǎn)eap，會(huì)導(dǎo)致線程的異常。

怎么處理呢？

這個(gè)時(shí)候safepoint就出場(chǎng)了。

safepoint就是一個(gè)安全點(diǎn)，所有的線程執(zhí)行到安全點(diǎn)的時(shí)候就會(huì)去檢查是否需要執(zhí)行safepoint操作，如果需要執(zhí)行，那么所有的線程都將會(huì)等待，直到所有的線程進(jìn)入safepoint。

然后JVM執(zhí)行相應(yīng)的操作之后，所有的線程再恢復(fù)執(zhí)行。

safepoint的例子

我們舉個(gè)例子，一般safepoint比如容易出現(xiàn)在循環(huán)遍歷的情況，還是使用我們之前做null測(cè)試用的例子：

public class TestNull { public static void main(String[] args) throws InterruptedException { List<String> list= new ArrayList(); list.add('www.flydean.com'); for (int i = 0; i < 10000; i++) { testMethod(list); } Thread.sleep(1000); } private static void testMethod(List<String> list) { list.get(0); }}

運(yùn)行結(jié)果如下：

標(biāo)紅的就是傳說(shuō)中的safepoint。

線程什么時(shí)候會(huì)進(jìn)入safepoint

那么線程什么時(shí)候會(huì)進(jìn)入safepoint呢？

一般來(lái)說(shuō)，如果線程在競(jìng)爭(zhēng)鎖被阻塞，IO被阻塞，或者在等待獲得監(jiān)視器鎖狀態(tài)時(shí)，線程就處于safepoint狀態(tài)。

如果線程再執(zhí)行JNI代碼的哪一個(gè)時(shí)刻，java線程也處于safepoint狀態(tài)。因?yàn)閖ava線程在執(zhí)行本地代碼之前，需要保存堆棧的狀態(tài)，讓后再移交給native方法。

如果java的字節(jié)碼正在執(zhí)行，那么我們不能判斷該線程是不是在safepint上。

safepoint是怎么工作的

如果你使用的是hotspot JVM，那么這個(gè)safepoint是一個(gè)全局的safepoint，也就是說(shuō)執(zhí)行Safepoint需要暫停所有的線程。

如果你使用的是Zing，那么可以在線程級(jí)別使用safepoint。

我們可以看到生成的匯編語(yǔ)言中safepoint其實(shí)是一個(gè)test命令。

test指向的是一個(gè)特殊的內(nèi)存頁(yè)面地址，當(dāng)JVM需要所有的線程都執(zhí)行到safepint的時(shí)候，就會(huì)對(duì)該頁(yè)面做一個(gè)標(biāo)記。從而通知所有的線程。

我們?cè)儆靡粡垐D來(lái)詳細(xì)說(shuō)明：

thread1在收到設(shè)置safepoint之前是一直執(zhí)行的，在收到信號(hào)之后還會(huì)執(zhí)行一段時(shí)間，然后到達(dá)Safepint暫停執(zhí)行。

thread2先執(zhí)行了一段時(shí)間，然后因?yàn)镃PU被搶奪，空閑了一段時(shí)間，在這段時(shí)間里面，thread2收到了設(shè)置safepoint的信號(hào)，然后thread2獲得執(zhí)行權(quán)力，接著繼續(xù)執(zhí)行，最后到達(dá)safepoint。

thread3是一個(gè)native方法，將會(huì)一直執(zhí)行，知道safepoint結(jié)束。

thread4也是一個(gè)native方法，它和thread3的區(qū)別就在于，thread4在safepoint開(kāi)始和結(jié)束之間結(jié)束了，需要將控制器轉(zhuǎn)交給普通的java線程，因?yàn)檫@個(gè)時(shí)候JVM在執(zhí)行Safepoint的操作，所以任然需要暫停執(zhí)行。

在HotSpot VM中，你可以在匯編語(yǔ)言中看到safepoint的兩種形式：’{poll}’ 或者 ‘{poll return}’ 。

總結(jié)

本文詳細(xì)的講解了JVM中Safepoint的作用，希望大家能夠喜歡。

補(bǔ)充知識(shí)：JVM源碼分析之安全點(diǎn)safepoint

上周有幸參加了一次關(guān)于JVM的小范圍分享會(huì)，聽(tīng)完R大對(duì)虛擬機(jī)C2編譯器的講解，我的膝蓋一直是腫的，能記住的實(shí)在有點(diǎn)少，能聽(tīng)進(jìn)去也不多

1、什么時(shí)候進(jìn)行C2編譯，如何進(jìn)行C2編譯（這個(gè)實(shí)在太復(fù)雜）

2、C2編譯的時(shí)候，是對(duì)整個(gè)方法體進(jìn)行編譯，而不是某個(gè)方法段

3、JVM中的safepoint

一直都知道，當(dāng)發(fā)生GC時(shí)，正在執(zhí)行Java code的線程必須全部停下來(lái)，才可以進(jìn)行垃圾回收，這就是熟悉的STW（stop the world），但是STW的背后實(shí)現(xiàn)原理，比如這些線程如何暫停、又如何恢復(fù)？就比較疑惑了。

然而這一切的一切，都涉及到一個(gè)概念safepoint，openjdk的實(shí)現(xiàn)位于

openjdk/hotspot/src/share/vm/runtime/safepoint.cpp

什么是safepoint

safepoint可以用在不同地方，比如GC、Deoptimization，在Hotspot VM中，GC safepoint比較常見(jiàn)，需要一個(gè)數(shù)據(jù)結(jié)構(gòu)記錄每個(gè)線程的調(diào)用棧、寄存器等一些重要的數(shù)據(jù)區(qū)域里什么地方包含了GC管理的指針。

從線程角度看，safepoint可以理解成是在代碼執(zhí)行過(guò)程中的一些特殊位置，當(dāng)線程執(zhí)行到這些位置的時(shí)候，說(shuō)明虛擬機(jī)當(dāng)前的狀態(tài)是安全的，如果有需要，可以在這個(gè)位置暫停，比如發(fā)生GC時(shí)，需要暫停暫停所以活動(dòng)線程，但是線程在這個(gè)時(shí)刻，還沒(méi)有執(zhí)行到一個(gè)安全點(diǎn)，所以該線程應(yīng)該繼續(xù)執(zhí)行，到達(dá)下一個(gè)安全點(diǎn)的時(shí)候暫停，等待GC結(jié)束。

什么地方可以放safepoint

下面以Hotspot為例，簡(jiǎn)單的說(shuō)明一下什么地方會(huì)放置safepoint

1、理論上，在解釋器的每條字節(jié)碼的邊界都可以放一個(gè)safepoint，不過(guò)掛在safepoint的調(diào)試符號(hào)信息要占用內(nèi)存空間，如果每條機(jī)器碼后面都加safepoint的話，需要保存大量的運(yùn)行時(shí)數(shù)據(jù)，所以要盡量少放置safepoint，在safepoint會(huì)生成polling代碼詢問(wèn)VM是否要“進(jìn)入safepoint”，polling操作也是有開(kāi)銷(xiāo)的，polling操作會(huì)在后續(xù)解釋。

2、通過(guò)JIT編譯的代碼里，會(huì)在所有方法的返回之前，以及所有非counted loop的循環(huán)（無(wú)界循環(huán)）回跳之前放置一個(gè)safepoint，為了防止發(fā)生GC需要STW時(shí)，該線程一直不能暫停。另外，JIT編譯器在生成機(jī)器碼的同時(shí)會(huì)為每個(gè)safepoint生成一些“調(diào)試符號(hào)信息”，為GC生成的符號(hào)信息是OopMap，指出棧上和寄存器里哪里有GC管理的指針。

線程如何被掛起

如果觸發(fā)GC動(dòng)作，VM thread會(huì)在VMThread::loop()方法中調(diào)用SafepointSynchronize::begin()方法，最終使所有的線程都進(jìn)入到safepoint。

// Roll all threads forward to a safepoint and suspend them allvoid SafepointSynchronize::begin() { Thread* myThread = Thread::current(); assert(myThread->is_VM_thread(), 'Only VM thread may execute a safepoint'); if (PrintSafepointStatistics || PrintSafepointStatisticsTimeout > 0) { _safepoint_begin_time = os::javaTimeNanos(); _ts_of_current_safepoint = tty->time_stamp().seconds(); }

在safepoint實(shí)現(xiàn)中，有這樣一段注釋?zhuān)琂ava threads可以有多種不同的狀態(tài)，所以掛起的機(jī)制也不同，一共列舉了5中情況：

1、執(zhí)行Java code

在執(zhí)行字節(jié)碼時(shí)會(huì)檢查safepoint狀態(tài)，因?yàn)樵赽egin方法中會(huì)調(diào)用Interpreter::notice_safepoints()方法，通知解釋器更新dispatch table，實(shí)現(xiàn)如下：

void TemplateInterpreter::notice_safepoints() { if (!_notice_safepoints) { // switch to safepoint dispatch table _notice_safepoints = true; copy_table((address*)&_safept_table, (address*)&_active_table, sizeof(_active_table) / sizeof(address)); }}

2、執(zhí)行native code

如果VM thread發(fā)現(xiàn)一個(gè)Java thread正在執(zhí)行native code，并不會(huì)等待該Java thread阻塞，不過(guò)當(dāng)該Java thread從native code返回時(shí)，必須檢查safepoint狀態(tài)，看是否需要進(jìn)行阻塞。

這里涉及到兩個(gè)狀態(tài)：Java thread state和safepoint state，兩者之間有著嚴(yán)格的讀寫(xiě)順序，一般可以通過(guò)內(nèi)存屏障實(shí)現(xiàn)，但是性能開(kāi)銷(xiāo)比較大，Hotspot采用另一種方式，調(diào)用os::serialize_thread_states()把每個(gè)線程的狀態(tài)依次寫(xiě)入到同一個(gè)內(nèi)存頁(yè)中，實(shí)現(xiàn)如下：

// Serialize all thread state variablesvoid os::serialize_thread_states() { // On some platforms such as Solaris & Linux, the time duration of the page // permission restoration is observed to be much longer than expected due to // scheduler starvation problem etc. To avoid the long synchronization // time and expensive page trap spinning, ’SerializePageLock’ is used to block // the mutator thread if such case is encountered. See bug 6546278 for details. Thread::muxAcquire(&SerializePageLock, 'serialize_thread_states'); os::protect_memory((char *)os::get_memory_serialize_page(), os::vm_page_size(), MEM_PROT_READ); os::protect_memory((char *)os::get_memory_serialize_page(), os::vm_page_size(), MEM_PROT_RW); Thread::muxRelease(&SerializePageLock);}

通過(guò)VM thread執(zhí)行一系列mprotect os call，保證之前所有線程狀態(tài)的寫(xiě)入可以被順序執(zhí)行，效率更高。

3、執(zhí)行complied code

如果想進(jìn)入safepoint，則設(shè)置polling page不可讀，當(dāng)Java thread發(fā)現(xiàn)該內(nèi)存頁(yè)不可讀時(shí)，最終會(huì)被阻塞掛起。在SafepointSynchronize::begin()方法中，通過(guò)os::make_polling_page_unreadable()方法設(shè)置polling page為不可讀。

if (UseCompilerSafepoints && DeferPollingPageLoopCount < 0) { // Make polling safepoint aware guarantee (PageArmed == 0, 'invariant') ; PageArmed = 1 ; os::make_polling_page_unreadable();}

方法make_polling_page_unreadable()在不同系統(tǒng)的實(shí)現(xiàn)不一樣

linux下實(shí)現(xiàn)

// Mark the polling page as unreadablevoid os::make_polling_page_unreadable(void) { if( !guard_memory((char*)_polling_page, Linux::page_size()) ) fatal('Could not disable polling page');};

solaris下實(shí)現(xiàn)

// Mark the polling page as unreadablevoid os::make_polling_page_unreadable(void) { if( mprotect((char *)_polling_page, page_size, PROT_NONE) != 0 ) fatal('Could not disable polling page');};

在JIT編譯中，編譯器會(huì)把safepoint檢查的操作插入到機(jī)器碼指令中，比如下面的指令：

0x01b6d627: call 0x01b2b210 ; OopMap{[60]=Oop off=460} ;*invokeinterface size ; - Client1::main@113 (line 23) ; {virtual_call} 0x01b6d62c: nop ; OopMap{[60]=Oop off=461} ;*if_icmplt ; - Client1::main@118 (line 23) 0x01b6d62d: test %eax,0x160100 ; {poll} 0x01b6d633: mov 0x50(%esp),%esi 0x01b6d637: cmp %eax,%esi

test %eax,0x160100 就是一個(gè)檢查polling page是否可讀的操作，如果不可讀，則該線程會(huì)被掛起等待。

4、線程處于Block狀態(tài)

即使線程已經(jīng)滿足了block condition，也要等到safepoint operation完成，如GC操作，才能返回。

5、線程正在轉(zhuǎn)換狀態(tài)

會(huì)去檢查safepoint狀態(tài)，如果需要阻塞，就把自己掛起。

最終實(shí)現(xiàn)

當(dāng)線程訪問(wèn)到被保護(hù)的內(nèi)存地址時(shí)，會(huì)觸發(fā)一個(gè)SIGSEGV信號(hào)，進(jìn)而觸發(fā)JVM的signal handler來(lái)阻塞這個(gè)線程，The GC thread can protect some memory to which all threads in the process can write (using the mprotect system call) so they no longer can. Upon accessing this temporarily forbidden memory, a signal handler kicks in。

再看看底層是如何處理這個(gè)SIGSEGV信號(hào)，實(shí)現(xiàn)位于

hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp// Check to see if we caught the safepoint code in the// process of write protecting the memory serialization page.// It write enables the page immediately after protecting it// so we can just return to retry the write.if ((sig == SIGSEGV) && os::is_memory_serialize_page(thread, (address) info->si_addr)) { // Block current thread until the memory serialize page permission restored. os::block_on_serialize_page_trap(); return true;}

執(zhí)行os::block_on_serialize_page_trap()把當(dāng)前線程阻塞掛起。

線程如何恢復(fù)

有了begin方法，自然有對(duì)應(yīng)的end方法，在SafepointSynchronize::end()中，會(huì)最終喚醒所有掛起等待的線程，大概實(shí)現(xiàn)如下：

1、重新設(shè)置pooling page為可讀

if (PageArmed) { // Make polling safepoint aware os::make_polling_page_readable(); PageArmed = 0 ; }

2、設(shè)置解釋器為ignore_safepoints，實(shí)現(xiàn)如下：

// switch from the dispatch table which notices safepoints back to the// normal dispatch table. So that we can notice single stepping points,// keep the safepoint dispatch table if we are single stepping in JVMTI.// Note that the should_post_single_step test is exactly as fast as the// JvmtiExport::_enabled test and covers both cases.void TemplateInterpreter::ignore_safepoints() { if (_notice_safepoints) { if (!JvmtiExport::should_post_single_step()) { // switch to normal dispatch table _notice_safepoints = false; copy_table((address*)&_normal_table, (address*)&_active_table, sizeof(_active_table) / sizeof(address)); } }}

3、喚醒所有掛起等待的線程

// Start suspended threads for(JavaThread *current = Threads::first(); current; current = current->next()) { // A problem occurring on Solaris is when attempting to restart threads // the first #cpus - 1 go well, but then the VMThread is preempted when we get // to the next one (since it has been running the longest). We then have // to wait for a cpu to become available before we can continue restarting // threads. // FIXME: This causes the performance of the VM to degrade when active and with // large numbers of threads. Apparently this is due to the synchronous nature // of suspending threads. // // TODO-FIXME: the comments above are vestigial and no longer apply. // Furthermore, using solaris’ schedctl in this particular context confers no benefit if (VMThreadHintNoPreempt) { os::hint_no_preempt(); } ThreadSafepointState* cur_state = current->safepoint_state(); assert(cur_state->type() != ThreadSafepointState::_running, 'Thread not suspended at safepoint'); cur_state->restart(); assert(cur_state->is_running(), 'safepoint state has not been reset'); }

對(duì)JVM性能有什么影響

通過(guò)設(shè)置JVM參數(shù) -XX:+PrintGCApplicationStoppedTime， 可以打出系統(tǒng)停止的時(shí)間，大概如下：

Total time for which application threads were stopped: 0.0051000 seconds Total time for which application threads were stopped: 0.0041930 seconds Total time for which application threads were stopped: 0.0051210 seconds Total time for which application threads were stopped: 0.0050940 seconds Total time for which application threads were stopped: 0.0058720 seconds Total time for which application threads were stopped: 5.1298200 secondsTotal time for which application threads were stopped: 0.0197290 seconds Total time for which application threads were stopped: 0.0087590 seconds

從上面數(shù)據(jù)可以發(fā)現(xiàn)，有一次暫停時(shí)間特別長(zhǎng)，達(dá)到了5秒多，這在線上環(huán)境肯定是無(wú)法忍受的，那么是什么原因?qū)е碌哪兀?/p>

一個(gè)大概率的原因是當(dāng)發(fā)生GC時(shí)，有線程遲遲進(jìn)入不到safepoint進(jìn)行阻塞，導(dǎo)致其他已經(jīng)停止的線程也一直等待，VM Thread也在等待所有的Java線程掛起才能開(kāi)始GC，這里需要分析業(yè)務(wù)代碼中是否存在有界的大循環(huán)邏輯，可能在JIT優(yōu)化時(shí)，這些循環(huán)操作沒(méi)有插入safepoint檢查。

以上這篇JVM系列之:再談java中的safepoint說(shuō)明就是小編分享給大家的全部?jī)?nèi)容了，希望能給大家一個(gè)參考，也希望大家多多支持好吧啦網(wǎng)。