Erlang常用經驗總結

1. receive子句的消息匹配模式：如果消息很簡單，使用atom就可以描述的話，沒必要使用tuple，tuple會消耗更多的內存，而且減慢了進程的處理速度。
2. i()列出當前進程的詳細信息，regs()列出所有註冊進程和端口的詳細信息。ets:i()列出所有ets表的詳細信息。
3. atom不會被垃圾回收，因此爲所有進程都進行註冊有可能會耗盡內存。建議只對長生命週期的進程進行註冊。
4. 給pid發送消息不會有任何錯誤，哪怕該進程不存在；但是，當註冊的進程不存在時，通過註冊名給它發消息會出錯。
5. 進程對接收到的消息不進行處理（匹配）應視爲一種bug，因爲這些未被處理的消息會不斷的在進程的mailbox裏堆積，最後引起內存泄露，然後，系統崩潰。mailbox過大的另一個問題是，每次收到新消息，所有的舊消息都要過一遍，從而減緩了進程的處理速度，表現爲CPU佔用率很高。此外，大容量mailbox的進程還會遲滯那些發消息給它的進程（因爲Erlang runtime爲了使大容量mailbox的進程能及時進行處理，它會主動放慢那些給這個進程發送消息的進程）
6. 但是，丟棄這些消息又會使調試困難，因此，最好確保在日誌中記錄下這些不能處理的消息。 
   通過優化代碼、對OS和Erlang VM精心調試可以糾正此類問題。 
   另外同步化發送消息的進程是一種辦法，發送進程發送一個消息然後等待一個確認會減慢maibox的消息增長速度。同步化的副作用是減少了接收處理進程的最大吞吐量，但至少不會使系統當掉。
7. Erlang無法完全避免死鎖，例如進程Ａ同步調用進程Ｂ（Ａ給Ｂ發送消息，然後等待Ｂ返回響應消息），後者（Ｂ）又同步調用進程A。
8. 進程的優先級可以通過調用process_flag(priority, Priority)進行調整，但是不鼓勵調整進程的優先級，甚至應該完全禁止使用。
9. 進程間的聯繫有兩種，一種是雙向的，即link；一種是單向的，即monitor。前者建立的聯繫是永久的，後者是臨時的。前者只能給存在的進程建立聯繫，後者可以監視不存在的進程（當然會立即收到一個{'DOWN'...,noproc}消息）。顯然後者適合用在不對稱關係的進程中，例如client-server
10. 解除對進程的監視最好調用erlang:demonitor(Reference, [flush])，因爲demonitor調用之前監視的進程可能就DOWN掉了。
11. 任一進程非正常退出，會給其link的進程集發出exit信號，exit信號將像多米諾骨牌一樣傳遞出去（每張牌就是一個進程，倒掉代表進程被結束）。可以理解成：調用process_flag(trap_exit,true)後，進程將收到的其它進程exit信息轉換成{'EXIT', Pid, Reason}消息，從而制止了多米諾骨牌的繼續倒掉；
12. 進程的正常結束不會引發關注：進程正常退出時，也會給它的直接link set發送exit信號，但這個正常退出信號不會進一步的傳播下去，也就是說正常退出信號不會引發多米諾骨牌的倒塌。（設置了trap_exit標誌的進程會將這個exit信號轉換成消息{'EXIT',Pid,normal}）。
13. 兩個在不同計算機上的link進程，如果它們之間的網絡連接斷掉了，會收到{'EXIT', Pid, noconnection}的消息
14. 大型的Erlang系統中不應該有孤兒進程，也就是說所有的進程都要連接在一棵巨大的supervision樹上。孤兒進程有兩個問題，首先不容易發現bug：當這些進程因bug當掉時，根本無從知曉。另一個問題是“進程泄漏”，孤兒進程因爲某種原因掛了起來，它會一直掛着，隨着越來越多的進程掛起，這些不斷積累的孤兒進程終將耗盡內存。
15. supervisor進程的唯一任務就是啓動子進程並監視之。supervisor設置成trap_exit，並link到所有子進程。
16. Erlang的在線升級，分兩種情況。第一種情況是模塊A在進程中運行，A會調用模塊B的函數，運行A模塊的進程會維持一個到模塊B的最新版本的鏈接（link），在模塊B重載後，進程中模塊B的鏈接（link）會切換到最新版本，這樣，模塊A以後會自動調用更新後的函數。第二種情況是模塊A本身的升級，這種正在進程中運行的模塊的升級要複雜一些，取決於模塊中函數的調用方式：是直接調用，還是fully qualified function call調用（指B:fun1()這樣的調用），如果是直接調用，在模塊重載後，還是維持舊版本的模塊，而 fully qualified函數調用將會立即切換到最新版本的函數。
17. Erlang運行時只維持兩個版本的模塊代碼，因此在第2次模塊升級後，最老版本的模塊會被移除，如果有進程仍然運行最老版本的模塊，這些進程將隨着最老版本模塊的移除而被終止（killed）。
18. 有三種裝載模塊的方法。第一種是直接調用模塊中的函數，此時一個叫code server的進程（它是Erlang kernel的一部分）將會搜索相應的beam文件，然後裝載之；第二種是編譯該模塊（相應的函數是compile:file(Module)）後會自動裝載編譯好的模塊，在shell中是通過命令c(Module)；第三章方式是顯式的裝載模塊，通過調用code:load_file(Module)轉載指定的模塊，在本機上可以通過命令l(Module)裝載模塊，在網絡中可以通過命令nl(Module)將模塊裝載到各個節點上。
19. Erlang運行時，同一個模塊至多維持有兩個：舊的和當前的。當又有新的版本裝載進來，舊的那個會被清除，當前的變成舊的，剛裝載上的成爲當前的。其中舊的、當前的模塊與該模塊實際版本無關，而與裝載的時間順序有關（可能先裝載一個最新版本的模塊，之後又裝載老版本的模塊，這種情況下先裝載的模塊是舊的，後裝載的模塊是當前的）。
20. shell中按tab鍵會顯示所有已裝載的模塊。
21. 調用code:is_loaded(Module)判斷模塊是否已裝載。shell中通過tab鍵補全特性判斷模塊是否已裝載。
22. code server的主要任務是動態的裝載和清除模塊。通過code模塊中的函數可以操作code server，進而對系統代碼庫進行管理和配置。
23. code search path是code server裝載模塊是的搜索路徑，缺省包括當前路徑，以及所有庫應用的路徑。通過code:get_path()查看。
24. Erlang根目錄：即Erlang安裝目錄，所有庫應用都在根目錄的lib目錄下，通過code:root_dir()可以查看根目錄位置。
25. 熱升級面臨的幾個問題：升級步驟原子化；向後兼容以備升級失敗；分佈式環境中升級的同步化。SASL應用庫提供了一些熱升級的工具。
26. 最簡單的熱升級是重載模塊即可。前提條件是升級不會修改已存在的loop data。
27. 既然函數也是一種數據，那麼顯然，它也可以是tuple的一部分、record的一部分，也可以作爲消息進行發送。當然，作爲其它函數的返回值也就沒什麼奇怪的，這樣就可以在運行時動態的創建函數了。
28. reference數據：在分佈式環境中reference數據提供了一個跨進程的唯一標識（tag），它主要用於進行比較，多於消息傳遞有關。
29. 用變量綁定已定義在模塊中的函數：Fun1 = fun Module:Function/Arity
30. 將函數傳遞給遠程節點時，顯然，函數中調用的那些模塊必須也在遠程節點的code search path中。
31. 一個binary是一塊無類型的內存的引用。最初被Erlang用來通過網絡加載代碼，隨後就應用在基於socket的通訊中。
32. ets的match操作有可能會損害Erlang系統的實時性：這是因爲所有的match操作都是作爲BIF實現的，而BIF的執行具有原子性，當對較大的ets表進行match操作時要遍歷完整個ets表，這就會堵塞其它進程。要避免此類問題最好用first、next遍歷ets表，這樣做也許會更慢，但至少不會損害系統的實時性。
33. 用ets存儲record數據要指定key位置，因爲作爲record的tuple第一個元素總是相同的。
34. 一個Erlang節點是指運行中的Erlang運行時系統。一個alive的Erlang節點是指“能夠”與其它節點通訊的節點，alive節點必須有名字。調用erlang:is_alive()判斷當前節點是否alive。net_kernel模塊提供了控制Erlang節點alive的函數。
35. alive的Erlang節點名字有兩種：短名(short name)和長名（long name），短名節點只能與短名節點通訊，長名節點只能與長名節點通訊。
36. Erlang系統的安全理念是：要麼完全信任你，要麼完全不信任你。因此互聯的遠程Erlang節點擁有本地節點的所有訪問權限。對於互聯網上分佈的Erlang節點，可以通過SSL加強安全性。
37. 節點間的安全是通過cookie控制的，每個節點持有一個被稱爲secret cookie的atom，持相同cookie的節點間才能進行通信。（home目錄下有個“.erlang.cookie”文件，其內容爲缺省cookie值。）另外，通過臨時設置cookie可以讓擁有不同cookie的節點間互通。
38. 分佈式節點間的互聯是通過每個節點上的net_kernel進程實現的，進程的遠程啓動也是net_kernel負責。net_kernel進程通過cookie進行安全授權。因此用戶可以通過修改net_kernel定製自己的安全授權機制。
39. 對於有太多Erlang節點的分佈式系統，一個問題是會有太多的TCP/IP連接，如果有N個節點，這些階段彼此聯通，會有N * (N - 1) / 2個TCP/IP連接。解決辦法是hidden node。
40. 通過node(hidden)或node(connected)查看hidden nodes
41. hidden node的一個用法是作爲“網關”將許多小的分佈式機羣連接起來。另一個用法是用來做維護，它不會影響流量。
42. 通用的消息發送格式是Pid ! Message，給遠程註冊進程發消息是：{register_name, node} ! Message
43. receive的timeout一個麻煩的地方是可能超時後消息又到了，這時消息就會堆積在接收進程的mailbox中，在該進程又一次進入消息接收時，可能處理的是這些超時後堆積的消息，因此進行消息接收之前最好flush一下進程的mailbox。
44. monitor_node(RemoteNode, true)用於監控遠程節點，當被監控的遠程節點當掉時監控進程會收到{nodedown, RemoteNode}消息。
45. 查詢某個進程（Pid）、某個引用（Reference）或者某個端口（Port）在哪個節點上，可以使用BIF函數node(Arg)。
46. epmd是Erlang port mapper deamon的縮寫，這是一個操作系統級的守護進程，是Erlang運行時系統的一部分。不管運行了多少Erlang節點，每個計算機只運行一個epmd，它隨Erlang節點的第一次啓動而啓動，不隨Erlang節點的結束而結束。epmd負責監聽4369端口上的連接請求，然後將其映射給相應節點的監聽端口。
47. epmd可以作爲shell命令單獨啓動，該命令還帶若干參數，可以通過 epmd -help查看。例如可以查看所有erlang節點的佔用端口。
48. epmd的一個重要用處是通過參數delay_accept和delay_write可以模擬網絡繁忙的情況，便於測試。
49. 程序員編寫的OTP應用（OTP application）是構成Erlang系統的磚石，它在運行時的進程組成一個supervision樹。OTP應用本身是一種OTP behavior。