最簡單最基礎死循環，一般都是這樣的
while(1) while(true) for( ; ; )……
然而在編程中常常會用到一些並不是那么基礎的死循環，
這里列舉一些我在編程中所遇到的一些死循環
方法已經不記得了，只是大概說明。
1(遞歸死循環)
2(AOP死循環)
這個是遞歸死循環的變種
學習Spring的同學都知道AOP面向切面編程，
記得網上讀過一篇博客說的是Spring中實現AOP不僅用到了jdk1.6的動態Proxy還使用了CGLIB。就可以實現接口和實體類都能被動態代理。
對動態代理一直不太了解。有天閑着無聊就試着了解一下：
CGLIB(Code Generation Library)詳解
https://blog.csdn.net/danchu/article/details/70238002
自己在網上找了幾篇文章看了一下，自己動手試試寫個 JDBC的事務注解 Transaction
這張圖不知道能不能大概說明意思，意思大概就是使用CGLIB進行動態代理的時候，注意盡量別調用被代理對象的toString方法。否則會間接遞歸死循環。
3(文件狀態更新死循環，這個有點極端，可能大家不會碰見)
這個是業務邏輯的系循環
大二的時候學安卓，用的是AndroidStudio 當時學校有一個比賽聯想智能交通的比賽，需要三個人用安卓坐一個app。當時思考一個問題，三個人做一個app一定在一個局域網下做一個app的，那么我能不能做個軟件讓三個人同時去操作一個項目。
思路是這樣的：
后台運行一個線程一直去遍歷一個指定的項目內的所有文件。如果一個文件的文件內容近期更改過。那就把文件發給好友。好友把更改的文件內容寫入到文件上去即可，。當然這些讀寫內容也都是后台線程完成的。
后來呢，這個東西的確也做出來了，但是呢，有編碼問題，后來就沒再管了。
同時里面有關於死循環的兩個問題值得思考
（1）子線程中就需要一個死循環，這個死循環的做用就是用來一直遍歷文件和查看文件更改狀態。當然這個死循環是一個正常的死循環，是我們所需要的死循環，無非就是損耗了軟件的性能
后來在網上查到一個文件監聽器的類。
WatchService watcher = FileSystems.getDefault().newWatchService();
這個類使用了觀察者模式。不需要再使用死循環了，無疑提高了軟件的性能。
（2）另一個死循環發生在文件讀寫時。
本來時當文件發生改變的時候發送文件到好友哪里去，由於每個客戶端有相同的功能。
那么問題就出在這里，當A的文件發生改變時，發送到B上去后，B把能讓更新到本地后那么本地文件又發生了改變，B就會把這個跟A一模一樣的文件再此發生給A。導致文件狀態更改引發死循環。