1. 有兩個問題關於c語言線程進程的，還望高手解答
程序的進度是以線程為單位向前推進的，很顯然線程屬於某一進程，進程擁有了程序實例的基本資源，在單核處理器的情況下，顯然系統中只能有一個線程在執行，而在多核的情況就有些復雜了，要看程序與系統如何處理。
你說的鎖應該是線程互斥量的使用，一般對於臨界代碼會使用類似於下面的代碼
pthread_mutex_lock(&mysql_mutex);
// some critical code ...
pthread_mutex_unlock(&mysql_mutex);
其實系統中的鎖並不是加給了要訪問的資源或執行的代碼，而是創建的互斥量，如果代碼不使用下面的機制
pthread_mutex_lock(&mysql_mutex);
// some critical code ...
pthread_mutex_unlock(&mysql_mutex);
直接
// some critical code ...
這肯定是可以執行的，但是這背離了我們使用鎖的初衷。
加鎖進程對一互斥量加鎖之後，是直接執行臨界代碼的，然後再釋放互斥量，如果另一線程需要執行臨界代碼，同時又使用了鎖的機制，那麼它就會檢查互斥量是否被鎖住，如果被鎖住會阻塞等待，若不是，就會為互斥量加鎖，並隨之進入臨界代碼，最後釋放互斥量。
2. python GIL 和 線程鎖是不是同一個東西
今天看到一篇文章，講述的是幾個提升python性能的項目:傳送門
在看的過程中，接觸到一個名詞，一個從學python開始就一直看到，但是從來都是一知半解的名詞，心裡不開心，必須把它搞明白，對了，這個詞就是 GIL。網上搜索了一些資料，粗淺的理解了什麼是GIL，自己感覺學習的過程比較好，感覺略有收獲，老規矩，為了鞏固知識，自己整片文章出來寫一寫，其實好多文章已經寫的很完善了，所以這篇隨筆，只做知識鞏固，如有雷同，請各位原創作者原諒，小菜鳥一枚，如果哪裡寫的有問題，還請各位前輩不吝指正。
一句話：解決多線程之間數據完整性和狀態同步的最簡單方法自然就是加鎖。
首先，GIL的全名，Global Interpreter Lock，鑒於英文水平，不做名詞翻譯，以免誤導。大體解釋一下，這個鎖就是用來為了解決Cpython多線程中線程不安全問題引入的一個全局排它鎖，它的作用就是在多線程情況下，保護共享資源，為了不讓多個線程同時操作共享資源，導致不可預期的結果而加上的鎖，在一個線程操作共享資源時，其他線程請求該資源，只能等待GIL解鎖。這個設置在Cpython剛引入多線程概念的時候就有了，然後後續的各種包和組件開發都不可避免的受到了GIL的影響，所以有人會說，python在多線程處理的時候很慢。python GIL實現方式類似於如下偽代碼：
if __name__ == '__main__':
GIL鎖開始運作
主線程做操作
主線程完成操作
GIL鎖釋放資源
所以多線程共同操作共享資源的時候，有一個線程競得了資源，它就被GIL鎖保護起來，其他線程只能是在那裡等著，但是這個時候，線程的休眠喚醒，全部會消耗CPU資源，所以嘞，就會慢。
看到這個時候，我又發現了一個名詞：線程安全。這個名詞，也是那種特別熟悉，但就是無法清晰的說出它是啥的概念。查了資料，在這記一下：
線程安全就是多線程訪問時，採用了加鎖機制，當一個線程訪問該類的某個數據時，進行保護，其他線程不能進行訪問直到該線程讀取完，其他線程才可使用。不會出現數據不一致或者數據污染。 線程不安全就是不提供數據訪問保護，有可能出現多個線程先後更改數據造成所得到的數據是臟數據。
我自己想了一下，大約就是這樣，比如整個列表，倆個線程同時在列表中append操作，如果沒有鎖的保護，在機緣巧合之下，倆個線程同時先後申請了空間且沒來得及插入數據，然後這時列表中只會有一個空間，那麼在插入過程中只能有一個數據寫入，會造成不可知後果，有可能報錯終止，有可能有一個線程操作沒成功，那麼這個就是線程不安全了，大白話說，只要線程之間沒有共享資源，那麼就是線程安全的，有共享資源，為了保證線程安全，需要引進鎖的機制。
而後的文章中，有前輩做過實驗：
過程證明了因為GIL的存在，導致python在使用多線程的時候反而不如順序執行快。
此處我又溫習了一下python線程：
線程的順序執行還是多線程並發，取決於join函數的位置。join函數的作用是等待當前線程結束，所以每一個線程創建之後，調用start函數，這是在後面跟上該線程的join函數，那麼就是順序執行，如果多個線程先完成創建和start，最後加上join函數，那麼就變成了多線程並發。
這就是今天的學習內容，其實所有知識網上都能找到，更想分享的是一種學習的方法，一種本身很不推薦的學習方法，那就是類似於探索性測試的學習，啥不懂就去看啥，有些時候，我們學習東西確實不能非要究其內在，軟體行業的學習本身在非本行人事看來就特別神奇且枯燥，所以最初的學習，我們需要整個圖形界面，讓我們學到的東西有了成就感，如果上來先去研究機器碼，那麼沒幾個人願意學下去，但是不管怎樣，既然走上了軟體行業的道路，這種探索性，打破砂鍋問到底的學習，在我的感覺里應該是必經之路，也就是所謂的底層研究。以安卓開發舉例，如果做安卓開發的，雖然能寫出很漂亮的界面，解決所有的bug，如果不了解安卓系統linux層的知識，在我的眼裡，從未把這種研發看做大牛。當然我並不覺得不了解linux底層的安卓研發可以解決任何bug
當下的軟體行業進入了一個神奇的階段，我已經聽過無數遍的理論，培訓機構出來就能賺錢，大學讀著沒用，在這里不討論教育體制問題，從個人情感上，我覺得大學教育雖然沒有教給學生直接找工作的技能，但是給了所有學生一個能夠了解基礎知識的園地，換而言之，作為行業的一員，總應該有將行業發展起來的覺悟，行業內整體風氣，缺乏靜下心來的沉澱。在大談敏捷，行為驅動，機器學習的同時，自己需要靜下心來回頭看看，基礎已然不牢，再走下去是否有些危險。是不是學習軟體技術，就是為了獲取互聯網行業那虛高的工資，是否已經局限於第三方框架，一旦框架出現問題，只能打給客服而束手無策，是否有過沒有做任何嘗試就將bug歸咎於安卓系統，阿里中間件等等，是不是舊技術還沒用明白，為了新技術就可以不再去研究。
還是小菜鳥，在此大談行業發展難免有些放肆，如有不對的地方，還請各位前輩不吝指正
3. 為什麼有人說 Python 的多線程是雞肋
多線程還是有用的，多進程有多進程的好處，多線程有多線程的好處。
多進程穩定，啟動時開銷大點，但如果你的運行時間遠大於多進程的時間，用多進程比較方便，如postgresql用多進程，chrome 多進程。
如果你只是想做個定時器樣的簡單東西，對穩定性要求低些，如vb,c#類似的定時器，用多線程吧，但線程的同步要注意了。python的線程更加類似定時器，python的線程不是真線程，但有的場合用這種定時器也能解決很多問題，因為開銷小，開啟也方便。
進程和線程，一個是重量級的，一個輕量級的，重量級的進程有保護區，進程上下文都是操作系統保護的，而線程是自己管理，需要一定的技術，不能保證在並發時的穩定性（多進程也不穩定，但很容易看出來，因為多出了進程容易發現），而python的更像是定時器，定時器有時也可以模擬線程，定時器多時的開銷比線程的開銷要小，真線程有下上文開銷，一個操作系統啟動多進程和多線程會達到切換飽和是有數量的，真線程或進程太多都會導致cpu佔用率居高不下，而定時器可以開n多。
很多東西不是一種比另外一種先進，而是一種互補的關系，計算機的計算單位切換有優點必有缺點，關鍵在找到合適的使用方式揚長避短。
4. 高手進，關於C語言在windows上建立多線程的問題（VC6.0上實現）
原因 是 在使用CreateThread 會造成一些 資源的無法釋放 比如c++對象
當然原因不止這些 還很有幾個 詳情 你可以參考windows核心編程
5. （C語言中）互斥鎖的死鎖問題
如果你將mutex_c換成mutex_p,則不會死鎖,因為,你第一個線程鎖上後,切換到第二個線程,因為mutex_p未釋放,第二個線程無法獲取mutex_p,進入等待狀態,此時OS將再次調度第一個線程,直到第一個線程釋放mutex_p之後,第二個線程才會被激活,然後調試第二線程,獲取mutex_p.
使用OS提供的互斥量來保護公共資源還是比較安全的,但如果用二值信號量的話,就可能會有優先順序反轉的情況.
6. 誰知道C++項目如何避免線程死鎖
要避免死鎖那麼首先應該知道死鎖產生的四個條件
死鎖產生的四個必要條件：
何為必要條件？
產生死鎖，必然四個條件成立；四個條件成立，不一定為死鎖
1互斥
只有互斥才可以產生死鎖，兩個進程共同操作一個資源，那麼，同一時間只能一個進程來操作，那麼另一個進程必須等待，此進程不釋放，另一個永遠等待。產生死鎖
2不可以強占
兩個進程，一個進程佔有某一個資源，另一個不可以強行佔有我的資源，如果可以佔有，那麼兩個進程都可以操作資源，那麼就不會產生死鎖。
3請求保持
我請求某一個資源的同時，保持對另一個資源的佔有。那麼我不釋放，那麼另一個進程才可能等待；如果釋放，那麼共同操作同一個資源，不會等待，也就不會死鎖。
4循環等待
a等待b的釋放資源，b等待c釋放資源，c卻等待a釋放資源。都在循環等待。
那麼避免死鎖就是要避免上述情況的出現
7. C語言：多線程(phread)中如何處理鏈表的增加、更新、刪除節點
兩者都可以～ 用線程鎖會稍稍簡單一些，不過如果對鏈表的操作很頻繁的話性能會比較差（一個鏈表一個鎖）～
8. java線程鎖有幾種
1、自旋鎖
2、自旋鎖的其他種類
3、阻塞鎖
4、可重入鎖
5、讀寫鎖
6、互斥鎖
7、悲觀鎖
8、樂觀鎖
9、公平鎖
10、非公平鎖
11、偏向鎖
12、對象鎖
13、線程鎖
14、鎖粗化
15、輕量級鎖
16、鎖消除
17、鎖膨脹
18、信號量