這些問題在任何面試中都可能太過提出而無法提出，因為它們可能會使候選人推遲。 不管怎樣，他們可能會在您自己的時間練習。

誤解1）System.exit（0）阻止最終被調用

為什么這樣的代碼

System.setSecurityManager(new SecurityManager() {@Overridepublic void checkExit(int status) {throw new ThreadDeath();}});try {System.exit(0);} finally {System.out.println("In the finally block");}

打印

In the finally block

為什么不打印堆棧跟蹤？

在此代碼中，str是一個String對象。

與C ++不同，所有變量都是基元或引用。 變量不能是對象。 這意味著當你有一個像

String str = "Hello"; String text = "Bye";str == text; // compares two references, not their contents. str = text; // assign the reference text has to str.

在許多情況下，差異不大，但會引起與此類線條的真正混淆。

final StringBuilder sb = new StringBuidler();sb.append("Hello"); // The reference sb is final, not the instance it references.method(sb); // method can alter the instance, but it cannot change the reference.

誤解3）Java內存泄漏是C ++開發人員可以理解的。

在Wikipedia上，內存泄漏是

在計算機科學中 ，當計算機程序錯誤地管理內存分配時，就會發生內存泄漏 。 在面向對象的編程中 ，當對象存儲在內存中但無法被運行的代碼訪問時，可能會發生內存泄漏。

但是，在Java中，對象始終是可訪問的，并且清除了那些不能強烈訪問的對象。 Java中的內存泄漏一詞是指； 保留內存的任何不希望有的增加，通常是由于在不再需要資源時將其記錄在集合中。

如果沒有紀律，則多線程很難。 如果僅將一堆代碼和一堆線程放在一起，就會遇到一個很難解決的問題，這將是一團糟。 但是，如果只使用所需數量的線程，控制線程之間的交互方式，并使用團隊中每個人都能理解的一些簡單模式，則問題將變得非常簡單。 接下來的挑戰是使整個團隊都遵守規則。

最近，我讀了一個涉及整數加法，內存訪問，模數和打印到控制臺的問題。 盡管每個操作都比該列表中的每個操作慢幾個數量級，但該人員仍在嘗試加快最快的操作速度，但是使用了更昂貴的操作。

當您想提高性能時，您需要用便宜的操作代替更昂貴的操作，并且如果瓶頸是硬件（例如，讀取硬盤驅動器上的數百萬個文件），則更改軟件無濟于事，因為這不是問題的根源。

誤解6）隨機數總是看起來隨機

隨機數的特定組合與帶模式的數一樣可能。 這個問題是我在此博客上提出的問題的轉貼。 許多人不敢相信隨機數生成器會產生一個看起來根本不是隨機的序列。

誤解7）浮點數應避免，因為它具有隨機誤差。

每次相同的操作，浮點都會產生相同的錯誤。 該錯誤是可預測的，因此是可管理的。 如果您知道自己在做什么，并遵循一些簡單的規則（例如，對結果四舍五入），則浮點代碼與使用BigDecimal相比，不會出錯，但它更易于閱讀并且速度提高了大約100倍（并且不會產生垃圾）。

誤解8）時區是永恒的

造成混淆的常見原因是，隨著時間的推移，時區會發生變化。 這意味著歐洲/倫敦時代是1970/1/1 01:00而不是00:00，為什么？ 在1968年到1970年之間，倫敦的夏令時為2.5年。

在過去幾年中，許多其他時區發生了變化。 莫斯科是GMT + 3，現在是GMT + 3（從2011年3月27日開始）。如果您查看2010年的某個時間，應該會看到GMT + 3不是+4。

因為您認為這聽起來很奇怪，

• 在瑞典1721年2月30日
• 在英國1751年，第一天是3月25日，與法國相差11天。
• 當美國采用公歷時，它是追溯性的，因此記錄了幾百年的日期可以參考這兩個日歷。 （通常給兩個日期以盡量減少混亂），例如喬治華盛頓的生日從1731年2月11日更改為1732年2月22日。

誤解9）當您在一個線程中讀取一個非易失性值時，最終會看到一個更新的值。

最后一天在StackOverflow上出現了兩次。 基本上，JIT可以優化代碼，使其內聯線程不變的非易失性字段。 一旦代碼編譯完成（您可以使用-XX：+ PrintCompilation看到它），它可能永遠不會看到您稍后在另一個線程中執行的更改。 添加隨機同步塊或打印語句可能會減慢過程或使JIT迷惑，并且它不會執行優化（無論是及時執行還是完全執行）。 有關更多信息，請說明何時需要揮發物

誤解10）關于Java面試問題的大多數內容都是準確的。

很高比例的Java面試問題要么已經過時（僅十年以上，并且不適用于Java的任何現代版本），要么具有誤導性，或者完全是錯誤的。 不幸的是，這些文件未經檢查就被編譯和回收了。 我會在StackOverflow上查看答案，因為它們的碼頭評論更好。 最重要的是，避免使用質量令人驚訝的持續低劣的印度玫瑰之類的網站。 如果您感到學究，請嘗試查找一篇文章中可以找到多少拼寫錯誤（使用班級名稱和技術術語）和神話。 問題的一部分是沒有有效的方法來提供反饋并糾正這些問題。

翻譯自: https://www.javacodegeeks.com/2014/05/common-java-myths.html

總結

以上是生活随笔為你收集整理的常见的Java神话的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。