java遞歸改為循環(huán)后為什么不會導致棧內存溢出？我們知道，在編程中，如果您想讓業(yè)務重復執(zhí)行，通常有兩種方法來實現(xiàn)：遞歸和循環(huán)。在實際的編碼過程中，我們不建議使用遞歸，而是建議使用循環(huán)。為什么？事實上，

java遞歸改為循環(huán)后為什么不會導致棧內存溢出？

我們知道，在編程中，如果您想讓業(yè)務重復執(zhí)行，通常有兩種方法來實現(xiàn)：遞歸和循環(huán)。在實際的編碼過程中，我們不建議使用遞歸，而是建議使用循環(huán)。為什么？

事實上，不僅僅是Java，任何編程語言，如果遞歸寫入錯誤，都可能導致內存溢出

！學習過Java的朋友一定或多或少聽說過并理解了堆棧內存和堆內存。程序運行時，計算機操作系統(tǒng)會給每個進程分配堆內存和堆棧內存，分配的堆棧內存有一個上限。一旦超過上限，就會導致內存溢出。

為什么遞歸操作容易導致內存溢出？主要原因如下：

在遞歸方法中，如果終止遞歸的條件寫得不正確，可能導致無限遞歸，最終導致內存溢出；

即使遞歸方法和退出遞歸條件正常，如果遞歸深度太深（遞歸次數(shù)太多），也會導致堆棧內存溢出！因為棧入棧出的規(guī)則是先入后出（先入后出），如果遞歸次數(shù)過多，就會導致只入不出棧，最后導致棧內存溢出。

將遞歸寫入方式改為循環(huán)寫入方式的優(yōu)點是不會在短時間內出現(xiàn)只進不出棧的現(xiàn)象，避免了棧內存溢出的現(xiàn)象。

為什么許多程序員從來都不用break或者continue語句？

很多人從語法的角度思考，這肯定很難理解。畢竟，存在是合理的。如果這兩樣東西有問題，就不會出現(xiàn)。一些公司禁止這樣做，主要是為了降低項目的復雜性。一個團隊有專家，新人，人員流動，后期維修問題。如果一個函數(shù)有多個嵌套循環(huán)和多個break continue，編寫時可能會認為沒問題，但接手的人可能要分析很長時間，很容易出錯。我們不能僅僅從自己的角度來分析問題的合理性