轉：http://cryolite.iteye.com/blog/419235

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