源碼位置位于安裝目錄的lib/stdlib/src下。

?

之前在使用gen_server時，由于之前自己實現過一個gen_server，因此對它內部的機制也能知道個七七八八，最近在用erlang的fsm模塊，突然想讀一讀它得源碼，這才突然發現erlang的源碼內部還是做了很復雜的工作，尤其是有個“陰魂不散”的模塊proc_lib。

?

無論是gen_server也好，gen_fsm也好，實際上在start的時候，都是調用的底層gen模塊的start/start_link函數，由start函數調用do_spawn函數，在這里，就和我之前想象的不一樣了，在我之前的印象里，這里應該直接用spawn，回調用戶編寫的init函數，但是，實際上不是這樣的，我們看下源碼：

Time = timeout(Options)，? ? %這個函數獲取timeout的時間，默認為infinity

然后開始調用proc_lib的start函數:

proc_lib:start(?MODULE, init_it, [GenMod, self(), self(), Name, Mod, Args, Options], Time, spawn_opts(Options))

?

其中，spawn_opts實在獲取spawn的參數。

?

我們跟進到proc_lib的內部，看看start函數做了些什么。

?

在start函數的第一行返回了一個Pid，那么我們已經能夠猜到spawn_opt內部應該是spawn新的進程了。在spawn_opt函數中，首先獲取了Parent(proc_lib進程的名字)以及Ancestors，然后調用erlang模塊的spawn_opt函數。

這個函數會調用當前進程的init_p方法，現在要注意，此時spawn_opt派生了新的進程，那么原來的parent進程會直接返回一個Pid，這個Pid就被我們之前看到的proc_lib:start的地方接收了，并且繼續向下執行了sync_wait(Pid, Timeout)函數，在sync_wait函數的內部在等待接收消息，如果超過timout的時間沒有接收到，就認為失敗了，那么我們可以推測，派生出來的進程一定是去執行用戶的init的函數去了，并且在執行完后會發給parent進程一個消息。

?

我們看看我們的猜測對不對，繼續跟進到init_p函數內部，我們可以看到函數內部開始搜刮者用戶傳遞進來的Fun的所有信息，并放入進程字典中(真的不喜歡進程字典)，然后開始執行用戶的Fun函數，然后該進程結束。

?

是的，你沒有看錯，你沒有發現任何地方向parent進程發送了ack信號，這不科學，因為這意味著parent會因為超時而報錯，如果你這么想，你一定是把執行的Fun函數當成了你的init，我們網上看就能發現實際上是gen模塊的init_it函數，這里還有個不太好的地方就是init_it調用了函數init_it2…這命名規則著實讓人蛋疼……

?

init_it2回調了用戶傳入的init_it函數，這個函數是由對應的行為模式編寫的init_it函數，比如舉個簡單的例子，在gen_server的源碼中，init_it就調用了用戶傳入的init函數，并且在執行后，調用init_ack，init_ack函數向parent進程發送了一個成功的消息，之后，gen_server進入loop函數開始接收消息，也就是說，用戶的gen_server:start()函數執行完畢。也印證了我們之前的猜想是正確的。

?

?

其實，這里我有個疑問，不知道作者為什么不把proc_lib:init_ack函數放在proc_lib的init_p函數的最后執行呢？

?

我們只是簡單的分析了proc_lib的spawn與直接spawn有哪些不同，那么對于我們來說，proc_lib還有哪些直接挖掘的呢？為什么要用proc_lib去包裝spawn呢？

?

翻翻proc_lib的代碼，在上文中，我們也可以看出，在spawn之前，保存了不少信息，比如parent進程的信息和相關的函數信息，這些在用procss_info查看時，都可以直觀的看到。同時，模塊向外暴露的initial_call函數，translate_initial_call函數以及raw_initial_call函數也可以查看。至于函數內部的實現就不多討論了，比較簡單。

?

最后，我們會發現還有個有趣的函數crash_report，我們分析源碼能夠看出，對于proc_lib派生的進程來說，退出信號是normal以及shutdown都會被認為是正常退出。其他的出錯信息會被error_logger模塊捕捉。

?

最后的最后，還有一個非常有意思的函數，就是hibernate函數，這個函數看起來就讓java程序員很親切，官方手冊上，對erlang模塊的hibernate函數的解釋大約是把當前正在運行的線程處于一個wait的狀態，此時，進程會拋棄掉自己的調用棧，并且進行gc，然后wait，直到信箱中接受到了新的消息。很明顯的，這種情況應該是當前進程在一段時間內預計不會收到消息，為了節省內存而觸發的，在高并發的場景下對內存的節省會起到一定的作用。同時，文檔上還說，當進程收到新的消息被喚醒，并且將函數的控制權交給作為參數被傳入的Fun。

?

問題出現了，既然調用棧被拋棄了，那么Fun執行完后何去何從？顯然進程這不就直接結束了？當然不是，proc_lib對hibernate做了個封裝，當被喚醒時會回調用戶傳入的函數，比如gen_server，那么wake_hib最終會被回調，我們可以看到，在gen_server中，wake_hib在處理完剛剛接受到得消息后，重新回到了handle_msg的函數中繼續等待接收消息。

?

對于proc_lib，值得說說的也就這么多，代碼不是很長，大約700多行，這個模塊理解了，本身gen模塊東西也不多，那么所有的otp模式也就比較簡單了。

?

恩，就是這樣。

轉載于:https://www.cnblogs.com/chunming-d/p/3766054.html

總結

以上是生活随笔為你收集整理的[erlang]proc_lib源码浅析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。