代碼與硬件交互頻繁，軟件啟動即卡死，獨立進程、共享內存破局！

接到了一個“大活”，一臺上位機上連接8個工業相機，并且都需要實時檢測，還一幀都不能丟，我寫出了第一版程序，結果程序一運行，直接卡死！以前從來沒有遇到過這樣的問題，因為我以前做的視覺項目頂多也就兩個相機而已，而且還都不是實時檢測，所以這次我算是遇到難題了！

先說上位機環境，這八個工業相機每臺相機的幀率為58幀，程序在獲取相機圖片的時候不能丟幀，相機分辨率為2448*2048，不能提前ROI，上位機配置為I9 14900（24核32線程，最高睿頻5.8GHz）,64G內存。

開始，我想簡單了，我認為雖然相機幀率高點，但是將8個相機的取圖邏輯放在8個獨立的線程里面執行這臺機器應該是吃得消的，后面果然也吃得消，配合一張萬兆網卡加一臺萬兆交換機，取圖還算順利，但是，最后卻卡在了界面顯示上！

我所使用的編程框架是C#的WinForm，在開始編程的時候，我使用的是一臺工業相機進行的測試，相機取圖到界面刷新非常流暢，但是，當我整個軟件框架搭好以后，當所有相機全部啟用以后，軟件一開啟，只要所有相機開始取圖，軟件就直接卡那不動了！

剛開始，我還以為是線程沒有控制好，后面發現是界面刷新率不夠，簡單得說，我是把所有相機的圖片顯示寫在了一個程序里，但是WinForm有個特性，那就是操作界面必須在主線程上操作，這就導致了8個相機滿58幀的情況下，每秒需要刷新464張照片，這已經遠遠超過了WinForm所能接受的極限了！

進程獨立

因此，我想了一個辦法，那就是將所有相機的處理邏輯全部剝離了主程序，所有相機的處理全部采取單程序處理的方式，也就是相機部分的全部采取獨立軟件、獨立進程的處理方式，這樣相當于開了9個程序，即主程序加8個相機圖像處理的程序。

單進程

但是，問題又隨之而來，那就是程序獨立了，但是相機還需要和主程序進行交互。本身如果全部邏輯都在一個軟件上運行，這個交互邏輯其實并不復雜，但是，一旦程序獨立了，互相之間就需要一個橋梁來進行溝通。

我最開始使用的是TCP/IP的方式，即使用Server和Client交互的方式進行通訊，主程序為服務端，相機程序為客戶端。

可是，TCP/IP方式也許是我沒處理好，存在三個問題，第一個問題盡管是在同一臺上位機上，還是會有延遲，第二個問題就是我需要知道客戶端發送給服務端的數據服務端已經收到了，所以，服務端在收到客戶端消息的時候，還得給客戶端反饋一個信號，但是，客戶端是一直在處理數據的，接收反饋信號這些信號容易產生堆疊，導致客戶端處理的效率遠遠跟不上發送的效率，即可能客戶端發送了10張圖片的處理結果，但是同時又接到了20張服務端的反饋結果。第三個問題就是客戶端需要一直監聽服務端的心跳，避免連接失效。

總得來說，使用TCP/IP的通信方式，對于我這個項目來說，并不是太效率，有沒有辦法能做到數據處理更快，且又能保證服務端和客戶端都能準確收發數據呢？

有！我想到了兩種辦法，第一種是使用Redis作為中間數據中轉站，第二種是使用消息隊列。

使用Redis很快就被我排除了，因為我很不喜歡在上位機上安裝各種輔助型的軟件，因為工業軟件最怕這種程序之外的東西，我們需要的部署方式，就是將軟件直接拷貝到另外一臺機器上也能運行。

而消息隊列，我首選的是MQTT協議，但是，最后也被我放棄了，一來是MQTT協議也是基于TCP/IP的，二來，它和TCP/IP通訊有者同樣的問題，就是消息收發需要使用一定的機制確保雙方都能收到，第三個原因是我在網上沒有找到合適的庫，可能花點時間能找到MIT協議的庫吧，但是，眼下我找到了更合適的辦法！

那就是使用共享內存的方式進行通訊！

共享內存

共享內存的方式理解起來很簡單，那就是在內存里面單獨開辟出來一部分空間，客戶端負責往這部分空間里面去寫入數據，服務端負責在這部分空間里面去取數據。

這時候有人可能會問兩個問題。

第一個問題是，我擔心不擔心讀寫失敗的情況，我可以很負責任得說，我一點也不擔心，因為C#封裝了一系列方法，使得共享內存的讀寫變得非常簡單，一般情況下，邏輯處理好了，不存在讀寫失敗的情況。

第二個問題就是讀寫沖突的問題，因為同時有8個程序在往這個地址里面寫入數據，怎么防止線程安全的問題？

這就要牽扯到互斥了，C#提供了一個Mutex對象，Mutex對象是一種用于同步進程或者線程訪問共享資源的一種機制，它可以確保同一時間只有一個線程能夠訪問到資源，防止數據競爭和資源沖突。

但是，即使這樣，竟然可能會出現線程排隊的問題，因為8個相機每秒出464張圖片嘛，同時寫入內存的話，因為有互斥，所以同時只能寫入一條數據，這可能會造成等待。

但共享內存還有一個機制，就是通過共享內存文件名來給8個相機分別指定8個共享內存地址，這樣每個相機相當于只需要關心自己共享內存里面的數據即可，也就是每秒只需要向共享內存里面寫入58條圖片數據，這樣競爭壓力就小很多了！

最后，主程序只需要在8個共享內存地址里面去取對應的圖片處理數據，即可。因為是直接操作內存，因此，效率得以保證！

而且，所有的可行性方案中，幾乎沒有比共享內存更加效率的方案了！

結語

使用共享內存同樣需要注意幾個問題，第一個問題就是如何確保數據能夠形成隊列而不被下一條數據覆蓋，這里面牽扯到一個叫作“環形緩沖區”的概念，整個邏輯其實并不復雜，假設一個共享內存里面同時只會存在2條數據，那么，我們就得確保共享內存的空間大小能夠裝得下這兩個數據，但是，又如何知道在寫入數據的時候，我們應該往哪個位置放呢？

這其實很簡單，我們只需要在共享內存的文件頭里面增加標記即可，即索引機制，比如說我在第一次寫入數據的時候，順便在共享內存的頭部寫入個1，表示1這個位置已經被占了，那么第二次寫入的時候我就知道我需要在第二個位置寫入。

但是，第三次怎么辦呢？

很簡單，當我第三次發現共享內存頭部的索引位置為2時，表示上一次寫入的數據位置為2，那么，這次我重新從第一個位置開始寫入，這就是“環形緩沖區”的概念了。

有人又會問了，萬一兩個位置的數據還沒有被取出，就又有新數據進來了怎么辦呢？這個真沒辦法了，所以，我們需要保證共享內存數據讀取的效率以及給共享內存開辟足夠的數據長度空間，確保隊列數據長度始終不會被突破！