最近看了下多程序。
一種接近底層的實作方法是使用
os.fork()方法，fork出子程序。但是這樣做事有局限性的。比如windows的os子產品裡面沒有 fork()
方法。
windows：
。linux：
另外還有一個子產品：subprocess。這個沒整過，但從vamei的部落格裡看到說也同樣有局限性。
是以直接說主角吧 --- multiprocessing子產品。
multiprocessing子產品會在windows上時模拟出fork的效果，可以實作跨平台，是以大多數都使用multiprocessing。
下面給一段簡單的代碼，示範一下建立程序：
執行結果：
上面提到了兩個方法：run 和join
run：如果在建立process對象的時候不指定target，那麼就會預設執行process的run方法：
另：python源碼裡，process.run方法：
可見如果在執行個體化process時不指定target，就會執行預設的run方法。
還有一個join方法：
最上面示範的代碼中，在調用process的start方法後，調用了兩次join方法。這個join方法是幹什麼的呢？
官方文檔的意思是：阻塞目前程序，直到調用join方法的那個程序執行完，再繼續執行目前程序。
比如還是剛才的代碼，隻是把兩個join注釋掉了：
執行結果：
發現主程序不像之前那樣，等待兩個子程序執行完了，才繼續執行。而是啟動兩個程序後立即向下執行。
為了深刻了解，這次把p2的執行函數裡面睡眠時間調大，讓他多睡一會，然後保留p1的join，注釋掉p2的join，效果更明顯：
發現主線程隻是等待p1完成了，就會向下執行，而不會等待p2是否完成。
是以使用多程序的正常方法是，先依次調用start啟動程序，再依次調用join要求主程序等待子程序的結束。
然而為什麼要先依次調用start再調用join，而不是start完了就調用join呢，如下：
由：
改為：
執行效果：
發現是先執行完p1，再執行主線程，最後才開始p2。
今天上午一直困惑這個事，現在終于明白了。join是用來阻塞目前線程的，p1.start()之後，p1就提示主線程，需要等待p1結束才向下執行，那主線程就乖乖的等着啦，自然沒有執行p2.start()這一句啦，當然就變成了圖示的效果了。