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

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

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

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

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

進程獨立

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

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

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

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

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

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

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

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

那就是使用共享內(nèi)存的方式進行通訊！

共享內(nèi)存

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

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

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

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

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

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

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

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

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

結語

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

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

但是，第三次怎么辦呢？

很簡單，當我第三次發(fā)現(xiàn)共享內(nèi)存頭部的索引位置為2時，表示上一次寫入的數(shù)據(jù)位置為2，那么，這次我重新從第一個位置開始寫入，這就是“環(huán)形緩沖區(qū)”的概念了。

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