在我用無意義的重言式殺死你之前，這是要點

如果您的應(yīng)用程序接近實時，或者將代碼發(fā)送到Mars，則需要保留Java中默認(rèn)的Stack實現(xiàn)。 根據(jù)LinkedList編寫您自己的版本。

同樣，如果您的應(yīng)用程序是關(guān)鍵任務(wù)，并且希望堆棧由并發(fā)線程處理，則使用ConcurrentLinkedDeque或基于LinkedList編寫自己的Stack -只需確保添加和刪除操作是線程安全的即可。 這樣做時，請考慮并發(fā)鎖 。

您只需要原始電源，并且在push過程中不會被偶爾的打擾所困擾，并且您的Stack不會被并發(fā)線程操縱，然后使用ArrayDeque或繼續(xù)基于ArrayList編寫自己的Stack。

如果是多線程的，則根據(jù)ArrayQueue和util.concurrent鎖編寫自己的Stack 。

如果您拒絕閱讀Java Stack API和Java Deque API，而您只是個瘋子，那么請使用默認(rèn)實現(xiàn)。 而且，我保證，當(dāng)機器人占領(lǐng)世界時，不會顯示憐憫之心。

注意：事實是，除非出于某種原因，您想要將實現(xiàn)類命名為' Stack '，否則您可以自由地將所有Deque實現(xiàn)直接用作Stack。

既然已經(jīng)對默認(rèn)實現(xiàn)拋出了足夠多的麻煩，請注意幾分鐘，讓我快速總結(jié)一下。

我們知道Java Collection API中的Stack是從Vector內(nèi)部擴展的， Vector在內(nèi)部使用數(shù)組。 換句話說，Java將基于數(shù)組的實現(xiàn)用于其Stack 。

因此，讓我們看看為什么在兩個最受歡迎的Stack實現(xiàn)之間-數(shù)組和鏈表，Java選擇了數(shù)組。

有些答案很明顯，有些則沒有：

公平競爭

粗略地看一下數(shù)組和鏈表的add和remove方法（它們是Stack的push和pop方法的Struts），可以在整個板上進行恒定時間的檢索。

增長問題

數(shù)組是固定大小的，并且僅通過將數(shù)組復(fù)制到更大的數(shù)組即??可實現(xiàn)數(shù)組的增長 ，這并不是什么新聞。 在我們默認(rèn)使用Vector實現(xiàn)Stack的情況下，增量容量僅為兩倍。

這只是意味著，如果我們要向堆棧中添加80個元素，則內(nèi)部數(shù)組將被復(fù)制4次–分別為10、20、40和80。因此，也就是說，當(dāng)我們添加第80個元素時，push操作實際上需要O（N ）時間，因為在這種情況下，我們的N為80，所以使用該殘酷的深層副本將使您的程序至少稍稍停頓一下–您可以節(jié)省其他寶貴時間的寶貴小循環(huán)。

遺憾的是，與Vectors不同，您將無法指定java.util.Stack的初始大小或增量因子，因為沒有重載的構(gòu)造函數(shù)。

另一方面，盡管增長經(jīng)常會ArrayQueue ，但ArrayQueues的初始容量有一個甜美的重載構(gòu)造函數(shù)，如果您對堆棧的大小有一個大概的了解，這將派上用場。 此外，默認(rèn)初始容量是16用于ArrayQueue用于作為對10 Vector 。

時間和地點，我的朋友。 時間和地點

為了與數(shù)組公平，存儲在基于數(shù)組的堆棧中的對象只是對堆中實際對象（對于對象而言）或?qū)嶋H值（對于基元而言）的引用。

另一方面，在LinkedList的情況下，存儲項目的頂部上方有一個Node包裝器。 平均而言，每個存儲的對象（包括Node對象的內(nèi)部類，鏈接到下一個Node以及對項本身的引用）將在堆中花費約40字節(jié)的額外空間。

那么，ArrayQueue或LinkedList嗎？

數(shù)組在大多數(shù)情況下都是首選的，因為它們具有占用順序存儲器的獨特優(yōu)勢，并且它們提供了更快的訪問速度，而到達實際對象只是指針運算。 但是，對閾值項目（觸發(fā)調(diào)整大小的項目）的push和pop操作需要O(n)時間。 但是，平均而言，它需要花費固定時間（如果需要，可以攤銷固定時間）。

另一方面，使用LinkedList ，由于要花費更多的時間來構(gòu)造新節(jié)點并指向新節(jié)點，所以add操作比數(shù)組要慢。 不用說，新節(jié)點消耗的堆空間不是實際對象消耗的空間。 但是，由于沒有大小調(diào)整（或需要順序存儲），并且總是引用第一個元素，因此最壞的情況是保證了恒定的時間。

現(xiàn)在，當(dāng)您重新訪問本博客的第一部分時，請隨意說該死，默認(rèn)實現(xiàn)！！！

相關(guān)鏈接 ：

• http://onjava.com/pub/a/onjava/2001/10/23/optimization.html
• http://www.javaworld.com/javatips/jw-javatip130.html?page=1
• http://docs.oracle.com/javase/7/docs/api/java/util/RandomAccess.html
• http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/Vector.java

參考資料： 為什么我們的JCG合作伙伴 Arun Manivannan會使用Rerun.me博客中的后代 人 討厭使用java.util.Stack 。

翻譯自: https://www.javacodegeeks.com/2012/11/why-future-generations-will-hate-you-for-using-java-util-stack.html

總結(jié)

以上是生活随笔為你收集整理的为什么子孙后代会讨厌使用java.util.Stack的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。