代碼與硬件交互頻繁，軟件啟動(dòng)即卡死，獨(dú)立進(jìn)程、共享內(nèi)存破局！

接到了一個(gè)“大活”，一臺(tái)上位機(jī)上連接8個(gè)工業(yè)相機(jī)，并且都需要實(shí)時(shí)檢測(cè)，還一幀都不能丟，我寫(xiě)出了第一版程序，結(jié)果程序一運(yùn)行，直接卡死！以前從來(lái)沒(méi)有遇到過(guò)這樣的問(wèn)題，因?yàn)槲乙郧白龅囊曈X(jué)項(xiàng)目頂多也就兩個(gè)相機(jī)而已，而且還都不是實(shí)時(shí)檢測(cè)，所以這次我算是遇到難題了！

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

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

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

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

進(jìn)程獨(dú)立

因此，我想了一個(gè)辦法，那就是將所有相機(jī)的處理邏輯全部剝離了主程序，所有相機(jī)的處理全部采取單程序處理的方式，也就是相機(jī)部分的全部采取獨(dú)立軟件、獨(dú)立進(jìn)程的處理方式，這樣相當(dāng)于開(kāi)了9個(gè)程序，即主程序加8個(gè)相機(jī)圖像處理的程序。

單進(jìn)程

但是，問(wèn)題又隨之而來(lái)，那就是程序獨(dú)立了，但是相機(jī)還需要和主程序進(jìn)行交互。本身如果全部邏輯都在一個(gè)軟件上運(yùn)行，這個(gè)交互邏輯其實(shí)并不復(fù)雜，但是，一旦程序獨(dú)立了，互相之間就需要一個(gè)橋梁來(lái)進(jìn)行溝通。

我最開(kāi)始使用的是TCP/IP的方式，即使用Server和Client交互的方式進(jìn)行通訊，主程序?yàn)榉?wù)端，相機(jī)程序?yàn)榭蛻舳恕?/p>

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

總得來(lái)說(shuō)，使用TCP/IP的通信方式，對(duì)于我這個(gè)項(xiàng)目來(lái)說(shuō)，并不是太效率，有沒(méi)有辦法能做到數(shù)據(jù)處理更快，且又能保證服務(wù)端和客戶端都能準(zhǔn)確收發(fā)數(shù)據(jù)呢？

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

使用Redis很快就被我排除了，因?yàn)槲液懿幌矚g在上位機(jī)上安裝各種輔助型的軟件，因?yàn)楣I(yè)軟件最怕這種程序之外的東西，我們需要的部署方式，就是將軟件直接拷貝到另外一臺(tái)機(jī)器上也能運(yùn)行。

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

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

共享內(nèi)存

共享內(nèi)存的方式理解起來(lái)很簡(jiǎn)單，那就是在內(nèi)存里面單獨(dú)開(kāi)辟出來(lái)一部分空間，客戶端負(fù)責(zé)往這部分空間里面去寫(xiě)入數(shù)據(jù)，服務(wù)端負(fù)責(zé)在這部分空間里面去取數(shù)據(jù)。

這時(shí)候有人可能會(huì)問(wèn)兩個(gè)問(wèn)題。

第一個(gè)問(wèn)題是，我擔(dān)心不擔(dān)心讀寫(xiě)失敗的情況，我可以很負(fù)責(zé)任得說(shuō)，我一點(diǎn)也不擔(dān)心，因?yàn)镃#封裝了一系列方法，使得共享內(nèi)存的讀寫(xiě)變得非常簡(jiǎn)單，一般情況下，邏輯處理好了，不存在讀寫(xiě)失敗的情況。

第二個(gè)問(wèn)題就是讀寫(xiě)沖突的問(wèn)題，因?yàn)橥瑫r(shí)有8個(gè)程序在往這個(gè)地址里面寫(xiě)入數(shù)據(jù)，怎么防止線程安全的問(wèn)題？

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

但是，即使這樣，竟然可能會(huì)出現(xiàn)線程排隊(duì)的問(wèn)題，因?yàn)?個(gè)相機(jī)每秒出464張圖片嘛，同時(shí)寫(xiě)入內(nèi)存的話，因?yàn)橛谢コ猓酝瑫r(shí)只能寫(xiě)入一條數(shù)據(jù)，這可能會(huì)造成等待。

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

最后，主程序只需要在8個(gè)共享內(nèi)存地址里面去取對(duì)應(yīng)的圖片處理數(shù)據(jù)，即可。因?yàn)槭侵苯硬僮鲀?nèi)存，因此，效率得以保證！

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

結(jié)語(yǔ)

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

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

但是，第三次怎么辦呢？

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

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