迴圈，就是一次一次的重複。許多時候，需要做多次重複的事情，這個時候就需要迴圈了。迴圈，給我們帶來的極大的簡便。不敢想象，世界沒有迴圈和遞迴的**會是怎樣的！
但是，用迴圈的時候，乙個很重要的事情就是退出條件設定！！！迴圈雖好，但是不能總在迴圈裡面不出來（不出來就是死迴圈了）。不過一般而言，不是不出來，而是出不來，就是因為迴圈退出條件設定有問題。退出條件設定相關的有兩個元素：迴圈變數和比較條件。迴圈變數一般在迴圈中不斷變化，而比較條件則是迴圈變數迴圈變化的極限值（就是迴圈變數退出時候的達到的值），一般是常量（一般是固定的值，但是有的時候特殊需要也會弄成變數。強烈建議比較條件不要弄成變數，盡量用其他替代方案！）。
由於粗心，好幾次都搞成了死迴圈，在此一一列出。
1、 要注意型別的極值。經常的迴圈變數是用整數表示，那麼比較條件也是乙個整數。有一次，用了unsigned char 型別的迴圈變數，然後比較條件是256.但是，unsigned char的最大值是255，就是說，迴圈變數是永遠小於256的——死迴圈咯。
建議：這種情況，首先要做的，就是記幾個整數的極值，也就幾個（1位元組的，2位元組的，4位元組的）。另外，規避方案：該情況一般是用來計數的，個數一般不會太多，所以可以直接用int，應該可以都包含進去了；另外，如果是遍歷的話，可以指標+end指標 來作為結束條件。
2、 保證while迴圈中迴圈變數在變化。好幾次，在寫了while之後，在寫了一系列do something之後，最後忘了寫迴圈變數變化的**了(t_t)!當然，還有些情況就是，原來寫的好好的，但是，在do something之中有增加了幾個if判斷，而這裡continue的之前，忘了dosomething了。
建議：最完美的解決方案就是用for，該迴圈的迴圈變數變化、退出條件都是放在最開始了，之後的do something一般不用管了。當然，如果特殊需要，要用while，那麼就養成好習慣：while之後，大括號之後，立馬在之中寫迴圈變數變化語句，然後再寫do something。continue之前，一定要寫迴圈變數變化。當然，有些人、或者有些時候，迴圈變數變化也直接寫在while同一行了，比如讀檔案經常就這麼寫：while (eof != (fread(buff,1024,1,fp)))
3、 一次迴圈中，盡量保證迴圈變數就變化一次！有一次，我退出條件是用的」!=」來判斷的，而一次迴圈中迴圈變數可能有多次++，最後導致跳過了比較條件那個值，進入死迴圈。當然，這個可以用」<」,」>」來規避。這樣退出沒問題了，但是，在迴圈中的do something可能會做多次，因為迴圈變數可能會多變化了一次！所以，除非特殊需要，否則建議不要用。
4、 遞迴。遞迴，是寫的方便，用起來麻煩。思路清晰，實現方便，是遞迴的優勢；但是，一旦有問題，排查起來很麻煩，因為一層一層很多層，很難搞。所以，我一般對遞迴是敬而遠之。至於用遞迴，要注意的地方，我覺得還是退出條件。退出條件，我沒有什麼特別好的建議。但是，如果沒信心，那麼我建議用個計數器記錄深度，每遞迴一次，加1，如果達到一定的深度，那麼就直接return，退出的時候，也可以-1（根據需要）。這樣，至少深度不會死迴圈。當然，如果需要，廣度上也可以設個計數的。
http錯誤錦集
http 400 請求無效 http 401.1 未授權 登入失敗 http 401.2 未授權 伺服器配置問題導致登入失敗 http 401.3 acl 禁止訪問資源 http 401.4 未授權 授權被篩選器拒絕 http 401.5 未授權 isapi 或 cgi 授權失敗 http 403 ...
hive錯誤錦集
我的hive錯誤錦集 1 效能問題 乙個條件的錯誤 在去年寫了乙個hive指令碼，今年需求有變，條件細分。於是指令碼改動較大，也沒有考慮太多就開始改動。完成後測試執行速度，發現執行時間為改動前的三倍，當時需求很急，草草跑出資料提交了。後來又需要該指令碼來用，才想起來效率問題，於是開始研究速度慢下來的...
專案錯誤錦集
2018.5.29 自己搭建springcloud中遇見的問題 一.加入了feign客戶端但是卻說沒有找不到這個類，但是spring boot的parent的依賴已經引入了 解決方案 1.檢視feign客戶端是否加入value，確定是呼叫那個服務 2.雖然加入了spring boot的依賴但是沒有引...