前言
代碼死循環這個話題，個人覺得還是挺有趣的。因為只要是開發人員，必定會踩過這個坑。如果真的沒踩過，只能說明你代碼寫少了，或者是真正的大神。
盡管很多時候，我們在極力避免這類問題的發生，但有時候，死循環卻悄咪咪的就來了，坑你於無形之中。如果你讀完這篇文章，也許會對代碼死循環問題有一些新的認識，學到一些非常實用的經驗，少走一些彎路。
死循環的危害
讓我們一起先來了解一下，代碼死循環到底有哪些危害？
程序進入假死狀態： 當某個請求導致的死循環，該請求將會在很大的一段時間內，都無法獲取接口的返回，程序好像進入假死狀態一樣。cpu使用率飆升：代碼出現死循環后，由於沒有休眠，一直不斷搶占cpu資源，導致cpu長時間處於繁忙狀態，必定會使cpu使用率飆升。內存使用率飆升：如果代碼出現死循環時，循環體內有大量創建對象的邏輯，垃圾回收器無法及時回收，會導致內存使用率飆升。同時，如果垃圾回收器頻繁回收對象，也會造成cpu使用率飆升問題。StackOverflowError：在一些遞歸調用的場景，如果出現無限遞歸，最終會報StackOverflowError棧溢出，導致程序直接掛掉。
哪些場景會產生死循環？
1.一般循環遍歷
這里說的一般循環遍歷主要是指：
- for語句
- foreach語句
- while語句
這三種循環語句可能是我們平常使用最多的循環語句了，但是如果沒有用好，也是最容易出現死循環的問題的地方。讓我們一起看看，哪些情況會出現死循環。
1.1 條件恆等
很多時候我們使用for語句循環遍歷，不滿足指定條件，程序會自動退出循環，比如：
for(int i=0; i<10; i++) {
System.out.println(i);
}
但是，如果不小心把條件寫錯了，變成這樣的：
for(int i=0; i>=0; i++) {
System.out.println(i);
}
結果就悲劇了，必定會出現死循環，因為循環中的條件變成恆等的了。
很多朋友看到這里，心想這種錯誤我肯定不會犯的。不過我需要特別說明的是，這里舉的例子相對來說比較簡單，如果i>10這里是個非常復雜的計算，還真說不准一定不會出現死循環。
1.2 不正確的continue
for語句在循環遍歷數組和list時更方便，而while語句的使用場景卻更多。
有時候，在使用while語句遍歷數據時，如果遇到特別的條件，需要用continue關鍵字跳過本次循環，直接執行下次循環。
例如：
int count = 0;
while(count < 10) {
count++;
if(count == 4) {
continue;
}
System.out.println(count);
}
當count等於4時，不打印count。
但如果continue沒有被正確使用，可能會出現莫名奇怪的問題：
int count = 0;
while(count < 10) {
if(count == 4) {
continue;
}
System.out.println(count);
count++;
}
當count等於4時直接推出本次循環，count沒有加1，而直接進入下次循環，下次循環時count依然等4，最后無限循環了。
這種是我們要千萬小心的場景，說不定，已經進入了死循環你還不知道呢。
1.3 flag線程間不可見
有時候我們的代碼需要一直做某件事情，直到某個條件達到時，有個狀態告訴它，要終止任務了，它就會自動退出。
這時候，很多人都會想到用while(flag)實現這個功能：
public class FlagTest {
private boolean flag = true;
public void setFlag(boolean flag) {
this.flag = flag;
}
public void fun() {
while (flag) {
}
System.out.println("done");
}
public static void main(String[] args) throws InterruptedException {
final FlagTest flagTest = new FlagTest();
new Thread(() -> flagTest.fun()).start();
Thread.sleep(200);
flagTest.setFlag(false);
}
}
這段代碼在子線程中執行無限循環，當主線程休眠200毫秒后，將flag變成false，這時子線程就會自動退出了。想法是好的，但是實際上這段代碼會進入死循環，不會因為flag變成false而自動退出。
為什么會這樣？
線程間flag是不可見的。
這時如果flag加上了volatile關鍵字：
private volatile boolean flag = true;
會強制把共享內存中的值刷新到主內存中，讓多個線程間可見，程序可以正常退出。
2.Iterator遍歷
除了前面介紹過的一般循環遍歷之外，遍歷集合的元素，還可以使用Iterator遍歷。當然並非所有集合都能使用Iterator遍歷，只有實現了Iterator接口的集合，或者該集合的內部類實現了Iterator接口才可以。
例如：
public class IteratorTest {
public static void main(String[] args) {
List<String> list = new ArrayList<>();
list.add("123");
list.add("456");
list.add("789");
Iterator<String> iterator = list.iterator();
while(iterator.hasNext()) {
System.out.println(iterator.next());
}
}
}
但如果程序改成這樣：
public class IteratorTest {
public static void main(String[] args) {
List<String> list = new ArrayList<>();
list.add("123");
list.add("456");
list.add("789");
while(list.iterator().hasNext()) {
System.out.println(list.iterator().next());
}
}
}
就會出現死循環。
這又是為什么呢？
如果看過ArrayList源碼的朋友，會發現它的底層iterator方法是這樣的實現的：
public Iterator<E> iterator() {
return new Itr();
}
每次都new了一個新的Itr對象。而hasNext方法的底層是通過判斷游標和元素個數是否相等實現的：
public boolean hasNext() {
return cursor != size;
}
每次new了一個新的Itr對象的時候cursor值是默認值0，肯定和元素個數不相等。所以導致while語句中的條件一直都成立，所以才會出現死循環。
❝我們都需要注意：在while循環中使用list.iterator().hasNext()，是個非常大的坑，千萬小心。
3.類中使用自己的對象
有時候，在某個類中把自己的對象定義成成員變量，不知道你有沒有這樣做過。
有些可能會很詫異，為什么要這么做。
假如，你需要在一個方法中調用另一個打了@Transactional注解的方法，這時如果直接方法調用，另外一個方法由於無法走代理事務會失效。比如：
@Service
public class ServiceA {
public void save(User user) {
System.out.println("業務處理");
doSave(user);
}
@Transactional(rollbackFor=Exception.class)
public void doSave(User user) {
System.out.println("保存數據");
}
}
這種場景事務會失效。
這時可以通過把該類自己定義成一個成員變量，通過該變量調用doSave方法就能有效的避免該問題。
@Service
public class ServiceA {
@Autowired
private ServiceA serviceA;
public void save(User user) {
System.out.println("業務處理");
serviceA.doSave(user);
}
@Transactional(rollbackFor=Exception.class)
public void doSave(User user) {
System.out.println("保存數據");
}
}
當然還有其他辦法解決這個問題，不過這種方法是最簡單的。其他的解決方案，可以看看我的另一篇文章《讓人頭痛的大事務問題到底要如何解決？》。
那么問題來了，如果成員變量不是通過@Autowired注入，而是直接new出來的，可以嗎？
成員變量改成這樣之后：
private ServiceA serviceA = new ServiceA();
項目重新啟動，程序進入無限循環。不斷創建ServiceA對象，但一直都無法成功，最后會報java.lang.StackOverflowError棧溢出。當棧深度超過虛擬機分配給線程的棧大小時就會出現此錯誤。
為什么會出現這個問題？
因為程序在實例化ServiceA對象時，要先實例化它的成員變量serviceA，但是它的成員變量serviceA，又需要實例化它自己的成員變量serviceA，如此一層層實例化下去，最終也沒能實例化。
而@Autowired注入為什么沒有問題？
因為@Autowired是在ServiceA對象實例化成功之后，在依賴注入階段，把實例注入到成員變量serviceA的。在spring中使用了三級緩存，通過提前暴露ObjectFactory對象來解決這個自己依賴自己的循環依賴問題。
對spring循環依賴問題有興趣的朋友，可以看看我之前寫的一篇文章《spring：我是如何解決循環依賴的？》。
4.無限遞歸
在日常工作中，我們需要經常使用樹形結構展示數據，比如：分類、地區、組織、菜單等功能。
很多時候需要從根節點遍歷找到所有葉子節點，也需要從葉子節點，往上一直追溯到根節點。
我們以通過根節點遍歷找到所有葉子節點為例。由於每次需要一層層遍歷查找，而且調用的方法基本相同。為了簡化代碼，我們一般都會選擇使用遞歸來實現這個功能。
這里我們以根據葉子節點找到根節點為例，大致代碼如下：
public Category findRoot(Long categoryId) {
Category category = categoryMapper.findCategoryById(categoryId);
if(null == category) {
throw new BusinessException("分類不存在");
}
Long parentId = category.getParentId();
if(null == categoryId || 0 == categoryId) {
return category;
}
return findRoot(parentId);
}
根據categoryId往上遞歸查找，如果發現parentId為null或者0的時候，就是根節點了，這時直接返回。
這可能是最普通不過的遞歸調用了，但是如果有人使壞，或者由於數據庫誤操作，把根節點的parentId改成了二級分類的categoryId一樣，比如都改成：1222。這樣遞歸調用會進入無限循環，最終會報java.lang.StackOverflowError異常。
為了避免這種慘案的發生，推薦使用如下方法。
可以定義一個運行遞歸的最大層級MAX_LEVEL，達到了最大層級則直接退出。以上代碼可以做如下調整：
private static final int MAX_LEVEL = 6;
public Category findRoot(Long categoryId, int level) {
if(level >= MAX_LEVEL) {
return null;
}
Category category = categoryMapper.findCategoryById(categoryId);
if(null == category) {
throw new BusinessException("分類不存在");
}
Long parentId = category.getParentId();
if(null == categoryId || 0 == categoryId) {
return category;
}
return findRoot(parentId, ++level);
}
先定義MAX_LEVEL的值，然后第一次調用遞歸方法的時候level字段的值傳1，每遞歸一次level的值加1，當發現level的值大於等於MAX_LEVEL時，說明出現了異常情況，則直接返回null。
❝我們在寫遞歸方法的時候，要養成好習慣，最好定義一個最大遞歸層級MAX_LEVEL，防止由於代碼bug，或者數據異常，導致出現無限遞歸的情況。
5.hashmap
我們在寫代碼時，為了提高效率，使用集合的概率非常大。通常情況下，我們喜歡先把數據收集到集合當中，然后對數據進行批處理，比如批量insert或update，提升數據庫操作的性能。
我們使用比較多的集合有：ArrayList、HashSet、HashMap等。我個人非常喜歡使用HashMap，特別是在java8中需要嵌套循環的地方，將其中一層循環的數據（list或者set）轉換成HashMap，可以減少一層遍歷，提升代碼的執行效率。
但是如果HashMap使用不當，可能會出現死循環，怎么回事呢？
5.1 jdk1.7的HashMap
jdk1.7的HashMap中采用 數組 + 鏈表 的結構存儲數據。在多線程環境下，同時往HaspMap中put數據時，會觸發resize方法中的transfer方法，進行數據重新分配的過程，需要重新組織鏈表的數據。
由於采用了頭插法，最終會形成key3的next等於key7，而key7的next又等於key3的情況，從而構成了死循環。
5.2 jdk1.8的HashMap
有了解決jdk1.7擴容時出現死循環的問題，在jdk1.8中對HashMap進行了優化，將jdk1.7中的頭插法改成了尾插法，另外采用 數組 + 鏈表 + 紅黑樹 的結構存儲數據。如果鏈表中元素超過8個時，就將鏈表轉化為紅黑樹，以減少查詢的復雜度，將時間復雜度降低為O(logN)。
在多線程環境下，同時往HaspMap中put數據時，會觸發root方法重新組織樹形結構的數據。
在for循環中會出現兩個TreeNode節點的Parent引用都是對方，從而構成死循環的情況。
5.3 ConcurrentHashMap
由於在多線程環境下，使用無論是jdk1.7，還是jdk1.8的HashMap會有死循環的問題。所以很多人建議，不用在多線程環境下，使用HashMap，而應該改用ConcurrentHashMap。
ConcurrentHashMap是線程安全的，同樣采用了 數組 + 鏈表 + 紅黑樹 的結構存儲數據，此外還是使用了 cas + 分段鎖，默認是16段鎖，保證並發寫入時，數據不會產生錯誤。
在多線程環境下，同時往ConcurrentHashMap中computeIfAbsent數據時，如果里面還有一個computeIfAbsent，它們的key對應的hashCode是一樣的，這時就會產生死循環。
意不意外，驚不驚喜？
幸好這個bug在jdk1.9中已經被Doug Lea修復了。
6.動態代理
我們在實際工作中，即使沒有自己動手寫過動態代理程序，但也聽過或者接觸過，因為很多優秀的開發框架，它們的底層必定都會使用動態代理，實現一些附加的功能。通常情況下，我們使用最多的動態代理是：JDK動態代理 和 Cglib，spring的AOP就是通過這兩種動態代理技術實現的。
我們在這里以JDK動態代理為例：
public interface IUser {
String add();
}
public class User implements IUser {
@Override
public String add() {
System.out.println("===add===");
return "success";
}
}
public class JdkProxy implements InvocationHandler {
private Object target;
public Object getProxy(Object target) {
this.target = target;
return Proxy.newProxyInstance(this.getClass().getClassLoader(),target.getClass().getInterfaces(),this);
}
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
before();
Object result = method.invoke(target,args);
after();
return result;
}
private void before() {
System.out.println("===before===");
}
private void after() {
System.out.println("===after===");
}
}
public class Test {
public static void main(String[] args) {
User user = new User();
JdkProxy jdkProxy = new JdkProxy();
IUser proxy = (IUser)jdkProxy.getProxy(user);
proxy.add();
}
}
實現起來主要有三步：
- 實現某個具體業務
接口 - 實現
InvocationHandler接口，創建調用關系 - 使用
Proxy創建代理類，指定被代理類的相關信息
這樣在調用proxy的add方式時，會自動調用before和after方法，實現了動態代理的效果，是不是很酷？
通常情況下，這種寫法是沒有問題的，但是如果在invoke方法中調用了proxy對象的toString方法，加了這段代碼：
proxy.toString();
程序再次運行，循環很多次之后，就會報java.lang.StackOverflowError異常。
很多人看到這里可能一臉懵逼，到底發生了什么？
代理對象本身並沒有自己的方法，它的所有方法都是基於被代理對象的。通常情況下，如果訪問代理對象的方法，會經過攔截器的invoke方法。但是如果在invoke方法調了代理對象的方法，比如：toString方法，會經過另外一個攔截器的invoke方法，如此一直反復調用，最終形成死循環。
❝切記不要在invoke方法中調用代理對象的方法，不然會產生死循環，坑你於無形之中。
7.我們自己寫的死循環
很多朋友看到這個標題，可能會質疑，我們自己會寫死循環？
沒錯，有些場景我們還真的會寫。
7.1 定時任務
不知道你有沒有手寫過定時任務，反正我寫過，是非常簡單的那種（當然復雜的也寫過，在這里就不討論了）。如果有個需求要求每隔5分鍾，從遠程下載某個文件最新的版本，覆蓋當前文件。
這時候，如果你不想用其他的定時任務框架，可以實現一個簡單的定時任務，具體代碼如下：
public static void downLoad() {
new Thread(() -> {
while (true) {
try {
System.out.println("download file");
Thread.sleep(1000 * 60 * 5);
} catch (Exception e) {
log.error(e);
}
}
}).start();
}
其實很多JDK中的定時任務，比如：Timer類的底層，也是用了while(true)的無限循環（也就是死循環）來實現的。
7.2 生產者消費者
不知道你有沒有手寫過生產者和消費者。假設有個需求需要把用戶操作日志寫入表中，但此時消費中還沒有引入消息中間件，比如：kafka等。
最常規的做法是在接口中同步把日志寫入表中，保存邏輯跟業務邏輯可能在同一個事務中，但為了性能考慮，避免大事務的產生，一般建議不放在同一個事務。
原本挺好的，但是如果接口並發量上來了，為了優化接口性能，可能會把同步寫日志到表中的邏輯，拆分出來，做成異步處理的。
這時候，就可以手動擼一個生產者消費者解決這個問題了。
@Data
public class Car {
private Integer id;
private String name;
}
@Slf4j
public class Producer implements Runnable {
private final ArrayBlockingQueue<Car> queue;
public Producer(ArrayBlockingQueue<Car> queue) {
this.queue = queue;
}
@Override
public void run() {
int i = 1;
while (true) {
try {
Car car = new Car();
car.setId(i);
car.setName("汽車" + i);
queue.put(car);
System.out.println("Producer:" + car + ", queueSize:" + queue.size());
} catch (InterruptedException e) {
log.error(e.getMessage(),e);
}
i++;
}
}
}
@Slf4j
public class Consumer implements Runnable {
private final ArrayBlockingQueue<Car> queue;
public Consumer(ArrayBlockingQueue<Car> queue) {
this.queue = queue;
}
@Override
public void run() {
while (true) {
try {
Car car = queue.take();
System.out.println("Consumer:" + car + ",queueSize:" + queue.size());
} catch (InterruptedException e) {
log.error(e.getMessage(), e);
}
}
}
}
public class ClientTest {
public static void main(String[] args) {
ArrayBlockingQueue<Car> queue = new ArrayBlockingQueue<Car>(20);
new Thread(new Producer(queue)).start();
new Thread(new Producer(queue)).start();
new Thread(new Consumer(queue)).start();
}
}
由於ArrayBlockingQueue阻塞隊列內部通過notEmpty 和 notFull 這兩個Condition實現了阻塞和喚醒機制，所以我們無需再做額外控制，用它實現生產者消費者相對來說要容易多了。
1.3 自己寫的死循環要注意什么？
不知道聰明的小伙伴們有沒有發現，我們自定義的定時任務和生產者消費者例子中，也寫了死循環，但跟上面其他的例子都不一樣，我們寫的死循環沒有出現問題，這是為什么？
定時任務中我們用了sleep方法做休眠：Thread.sleep(300000);。
生產者消費者用了Condition類的await和signal方法實現了阻塞和喚醒機制。
這兩種機制說白了，都會主動讓出cpu一段時間，讓其他的線程有機會使用cpu資源。這樣cpu有上下文切換的過程，有一段時間是處於空閑狀態的，不會像其他的列子中一直處於繁忙狀態。其他的問題，比如內存使用率飆升問題，也會得到相應的緩解。
❝一直處於繁忙狀態才是cpu使用率飆高的真正原因，我們要避免這種情況的產生。
就像我們平時騎共享單車（cpu資源）一樣，我們一般騎1-2小時就會歸還了，這樣其他人就有機會使用這輛共享單車。但如果有個人，騎了一個天還沒歸還，那么這一天當中自行車一直處於繁忙之中，其他人就沒有機會騎這輛自行車了。
最后說一句(求關注，別白嫖我)
傳統美德不能丟，如果讀完這篇文章有些收獲的話，記得關注一下我的公眾號，給我點個 在看 😙。你的支持是我繼續堅持寫作唯一的動力。
收藏等於白嫖，收藏等於白嫖，收藏等於白嫖。
求一鍵三連：點贊、轉發、在看。
關注公眾號：【蘇三說技術】，在公眾號中回復：面試、代碼神器、開發手冊、時間管理有超贊的粉絲福利，另外回復：加群，可以跟很多BAT大廠的前輩交流和學習。