當(dāng)前位置：首頁 > 编程语言 > java >内容正文

java

日月神话_常见的Java神话

發(fā)布時間：2023/12/3 java 38 豆豆

生活随笔收集整理的這篇文章主要介紹了日月神话_常见的Java神话小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

日月神話

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

誤解1）System.exit（0）阻止最終被調(diào)用

為什么這樣的代碼

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 ++不同，所有變量都是基元或引用。變量不能是對象。這意味著當(dāng)你有一個像

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內(nèi)存泄漏，因為C ++開發(fā)人員會理解它們。

在Wikipedia上，內(nèi)存泄漏是

在計算機(jī)科學(xué)中，當(dāng)計算機(jī)程序錯誤地管理內(nèi)存分配時，就會發(fā)生內(nèi)存泄漏。在面向?qū)ο蟮木幊讨?，當(dāng)對象存儲在內(nèi)存中但無法被運行的代碼訪問時，可能會發(fā)生內(nèi)存泄漏。

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

如果沒有紀(jì)律，則多線程很難。如果只是將一堆代碼和一堆線程放在一起，那么將很難解決，這將是一團(tuán)糟。但是，如果僅使用所需數(shù)量的線程，控制線程的交互方式，并使用團(tuán)隊中每個人都能理解的一些簡單模式，則問題將變得非常簡單。接下來的挑戰(zhàn)是使整個團(tuán)隊都遵守規(guī)則。

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

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

誤解6）隨機(jī)數(shù)總是看起來隨機(jī)

隨機(jī)數(shù)的特定組合與帶模式的數(shù)一樣可能。這個問題是我在此博客上提出的問題的轉(zhuǎn)貼。許多人不敢相信隨機(jī)數(shù)生成器會產(chǎn)生一個完全看起來不是隨機(jī)的序列。

誤解7）應(yīng)該避免浮點數(shù)，因為它具有隨機(jī)誤差。

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

誤解8）時區(qū)是永恒的

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

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

因為您認(rèn)為這聽起來很奇怪，

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

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

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

誤解10）關(guān)于Java面試問題的大多數(shù)內(nèi)容都是準(zhǔn)確的。

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

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