我們公司有個項目，需要視覺定位，大致就是在產(chǎn)品上會有一個“十字”形狀的Mark標記，然后通過視覺相機連續(xù)拍照，然后將拍到的圖片進行視覺算法運算，最終得出Mark標記的位置，然后根據(jù)其位置對設備進行位置糾正。但是，想不到就這么一個小功能卻出現(xiàn)了一個Bug，找了很久才發(fā)現(xiàn)原因！

說這個Bug之前，我需要先說下這個Bug是怎么被我寫出來的！說這個Bug之前，我需要先說下這個Bug是怎么被我寫出來的！

甲方那有一個設備，設備上有一個可以前后移動的軸，下稱M軸，軸上又裝了一個可以左右移動的軸，類似于貼片機的構造吧。我們用來視覺定位的相機就是裝在那個可以左右移動的軸上面的，下面簡稱P軸。

Mark標記處于P軸的初始位置，而且Mark的左右視野范圍被設定成不可超過P軸的初始位置，因此，要用Mark進行定位，只需要M軸前后移動，相機進行拍照即可，最后再根據(jù)Mark的位置調(diào)整P軸的位置。

最開始，我選擇的是一張一張得拍，并且我在封裝相機SDK的時候，取圖我只封裝了一個取單張圖片的接口。

后來發(fā)現(xiàn)算法速度跟不上M軸移動的速度，當相機拍了一張照片，然后程序再對照片進行視覺運算，中間會產(chǎn)生一定時間的間隙，當程序算完以后，M軸已經(jīng)移動很遠了，拍到下一張圖片的時候，信息就會丟失一部分空間畫面。

如果Mark恰巧處于這個空間之內(nèi)，那么很大概率就拍不到Mark標記了！

所以，我又在相機SDK里面重新封裝了一個接口，用來批量取圖，然后返回圖片地址列表，大致的邏輯就是根據(jù)視覺相機設置的幀率乘以M軸移動的總時間，換算出相機應該拍照的總照片數(shù)，假設相機幀率是10幀每秒，M軸總移動時間是3秒，那么應該取出的圖片就是10*3=30張。

這么做的目的就是在M軸移動的時候，純拍照片，然后將拍到的圖片保存在緩存目錄里面，其他什么都不做，這樣能讓視覺相機使用最大幀率去取圖，從而覆蓋M軸行程內(nèi)的所有空間。最后，循環(huán)所有已經(jīng)拍到的圖片，總有一張或者幾張圖片里面存在Mark標記！最后，再一次性返回所有圖片的保存地址。

雖然這個方案很好，但是在實際運行過程中卻出現(xiàn)了一個小的Bug，那就是Mark的檢測結果和實際展示圖片對不上！并且，還不是每次都會出現(xiàn)這樣的Bug，有時候就是好的。

癥狀就是，很多時候顯示的圖片里面明明沒有Mark標記，但是算法卻能識別出Mark標記來，或者有Mark標記，但是Mark標記被檢測出來的上下位置卻不一樣，可偏偏結果還是正確的！

最開始，我以為是算法有問題，后來這個問題很快被排除了。

那會不會是在循環(huán)圖片時，把圖片索引搞錯了呢？我仔細看了下我循環(huán)圖片，對圖片進行視覺運算的那段代碼，也沒發(fā)現(xiàn)問題。

本來，這個問題其實很好解決的，只要下個斷點調(diào)試一下就能發(fā)現(xiàn)問題出在哪，可偏偏軟件已經(jīng)部署在了甲方那里，問題只能通過我們公司放在甲方那邊的同事跟我復述，我通過在代碼里面加運行日志來分析問題出現(xiàn)的原因。

因為日志總歸是人加的，它只能被加在我可能認為會出問題的地方，一些我不認為會出現(xiàn)問題的地方我是不會加的。

但偏偏有一個地方我就忽略了！

前面說了，我在視覺相機的SDK里面重新封裝了一個批量取圖的接口，而這個接口的邏輯是通過一個觸發(fā)拍照命令，輸入指定數(shù)量的圖片和取圖時間來取圖的，取出來的圖是放在一個指針數(shù)組里面的，我需要循環(huán)將指針轉換成圖片對象，然后再保存到緩存目錄里。

因為圖片數(shù)量太多，為了保證轉換效率，所以，我在循環(huán)指針數(shù)組的時候，使用了線程池來轉換圖片，問題就出在這！

我外層使用的是一個普通的循環(huán)，因為我不光要取圖，還需要保存圖片，而圖片名稱的某一個規(guī)則就是循環(huán)的當前索引，如“20250624_0_.jpg”，其中“_0_”中的0就是循環(huán)索引i的值。

因為使用的是線程池來執(zhí)行取圖邏輯，那么在當前線程里面直接取i是有問題的！因為i的作用域是在循環(huán)內(nèi)部，但是，循環(huán)內(nèi)部如果執(zhí)行的是一個線程，那么每一個線程所獲得到的i和這個線程的作用域不一樣，那么就會導致這個線程取到的i實際并不是順序的！

這么說不理解的話，我舉一個極端的例子：

假設我們需要拍30張圖片，這30張圖片被存在了一個指針數(shù)組里，我們通過For循環(huán)去循環(huán)指針數(shù)組，每循環(huán)一次，在線程池里面加一個線程，用來將指針轉換成圖片，而此時，我們PC的線程數(shù)已經(jīng)被其他程序占用，因此，這30個線程都處于等待狀態(tài)，直到最后一次循環(huán)，此時i為30，循環(huán)完成后，此時前面被占用的線程瞬間被釋放，前面等待的這30個線程將全部執(zhí)行，此時，這30個線程里面取到的所有i值將都是30！

而此時保存圖片，所有圖片名稱都是一樣的，因為圖片保存走的是覆蓋流程，最后程序執(zhí)行下來，只會保存住一張圖片！

如果還不懂，請看示例：

這就是導致前面所有問題的根源！因為我在執(zhí)行批量取圖之后，我需要重新循環(huán)圖片地址列表去讀取圖片，然后對圖片進行視覺運算以及顯示。

結合上面所說，如果最后30張圖片所有的i都是30的話，那么最終保存的圖片數(shù)量就只有一張了，此時，圖片數(shù)量就是1。

此時，我如果使用For循環(huán)這么寫：

For(int I = 0;i<1;i++)

這么一來，這個循環(huán)索引0所獲取到的圖片實際上是 “20250624_30_.jpg”，此時，如果視覺算法通過了，我會將圖片索引保存，此時保存的所謂的圖片索引就是0。

顯然，索引為0的圖片并不存在，因此，在圖片顯示的時候，這時候畫面上就只有Mark標記框，而沒有實際圖片。

那假設批量取圖數(shù)量是30，但是因為線程的原因，最終保存在文件夾里的圖片只有15張會出現(xiàn)什么結果呢？

很顯然，這時候循環(huán)索引和所有圖片的實際索引就都錯位了！

我也在批量取圖后的那個循環(huán)讀取圖片的For循環(huán)里面也加過日志，但是恰巧當時這個問題沒出現(xiàn)，我以為程序已經(jīng)沒問題了，所以就將日志給去除了，后來再出問題時，就沒往這方面想了。

至于為什么不保存圖片地址而保存圖片循環(huán)的索引，這個是業(yè)務邏輯決定的。

當然，這么寫會出問題我是知道的，但是，您也知道，有時候寫代碼的事很難說，一個不注意寫出一個Bug其實很難發(fā)現(xiàn)的。

直到我查遍所有代碼，把所有可能性都一一排除以后，最后瞄了一眼我寫的相機SDK，一眼就發(fā)現(xiàn)了問題所在！

總結

在For循環(huán)中使用線程，并且在線程里面使用For循環(huán)的索引導致的錯誤，其實這是一個很經(jīng)典的線程安全案例，我在過去接觸到的很多年輕的程序員在使用線程的時候基本上都會遇到這個問題。

如何避免這個問題呢？其實很簡單，就是強制將For循環(huán)的作用域限制到當層循環(huán)之內(nèi)，寫法就是：

前后對比下，我只是將直接使用i的方式改成了先將i這個循環(huán)索引先賦值給變量index，然后再去使用，這樣，index這個變量的作用域就會被強制鎖定在當前循環(huán)內(nèi)，不管最終線程什么時候執(zhí)行，index的值不會變！