為什么等待和通知是在Object類而不是Thread中聲明的？

　　一個棘手的Java問題，如果Java編程語言不是你設計的，你怎么能回答這個問題呢。Java編程的常識和深入了解有助于回答這種棘手的Java核心方面的面試問題。

　　為什么wait，notify和notifyAll是在Object類中定義的而不是在Thread類中定義

　　這是有名的Java面試問題，招2~4年經驗的到高級Java開發人員面試都可能碰到。

　　這個問題的好在它能反映了面試者對等待通知機制的了解,以及他對此主題的理解是否明確。就像為什么Java中不支持多繼承或者為什么String在Java中是final的問題一樣，這個問題也可能有多個答案。

　　為什么在Object類中定義wait和notify方法，每個人都能說出一些理由。從我的面試經驗來看,wait和nofity仍然是大多數Java程序員最困惑的，特別是2到3年的開發人員，如果他們要求使用wait和notify,他們會很困惑。因此，如果你去參加Java面試，請確保對wait和notify機制有充分的了解，并且可以輕松地使用wait來編寫代碼，并通過生產者-消費者問題或實現阻塞隊列等了解通知的機制。

　　為什么等待和通知需要從同步塊或方法中調用,以及Java中的wait，sleep和yield方法之間的差異，如果你還沒有讀過，你會覺得有趣。為何wait，notify和notifyAll屬于Object類?為什么它們不應該在Thread類中?以下是我認為有意義的一些想法：

　　1)wait和notify不僅僅是普通方法或同步工具，更重要的是它們是Java中兩個線程之間的通信機制。對語言設計者而言,如果不能通過Java關鍵字(例如synchronized)實現通信此機制，同時又要確保這個機制對每個對象可用,那么Object類則是的正確聲明位置。記住同步和等待通知是兩個不同的領域，不要把它們看成是相同的或相關的。同步是提供互斥并確保Java類的線程安全，而wait和notify是兩個線程之間的通信機制。

　　2)每個對象都可上鎖，這是在Object類而不是Thread類中聲明wait和notify的另一個原因。

　　3)在Java中為了進入代碼的臨界區，線程需要鎖定并等待鎖定，他們不知道哪些線程持有鎖，而只是知道鎖被某個線程持有，并且他們應該等待取得鎖,而不是去了解哪個線程在同步塊內，并請求它們釋放鎖定。

　　4)Java是基于Hoare的監視器的思想。在Java中，所有對象都有一個監視器。

　　線程在監視器上等待，為執行等待，我們需要2個參數：

　　一個線程

　　一個監視器(任何對象)

　　在Java設計中，線程不能被指定，它總是運行當前代碼的線程。但是，我們可以指定監視器(這是我們稱之為等待的對象)。這是一個很好的設計，因為如果我們可以讓任何其他線程在所需的監視器上等待，這將導致“入侵”，導致在設計并發程序時會遇到困難。請記住，在Java中，所有在另一個線程的執行中侵入的操作都被棄用了(例如stop方法)。

　　為什么Java中不支持多重繼承？

　　我發現這個Java核心問題很難回答，因為你的答案可能不會讓面試官滿意，在大多數情況下，面試官正在尋找答案中的關鍵點，如果你提到這些關鍵點，面試官會很高興。在Java中回答這種棘手問題的關鍵是準備好相關主題,以應對后續的各種可能的問題。

　　這是非常經典的問題，與為什么String在Java中是不可變的很類似;這兩個問題之間的相似之處在于它們主要是由Java創作者的設計決策使然。

　　為什么Java不支持多重繼承,可以考慮以下兩點:

　　1)第一個原因是圍繞鉆石形繼承問題產生的歧義，考慮一個類A有foo()方法,然后B和C派生自A,并且有自己的foo()實現，現在D類使用多個繼承派生自B和C，如果我們只引用foo(),編譯器將無法決定它應該調用哪個foo()。這也稱為Diamond問題，因為這個繼承方案的結構類似于菱形，見下圖:

　　Afoo()

　　/\

　　/\

　　foo()BCfoo()

　　\/

　　\/

　　Dfoo()

　　即使我們刪除鉆石的頂部A類并允許多重繼承，我們也將看到這個問題含糊性的一面。如果你把這個理由告訴面試官，他會問為什么C++可以支持多重繼承而Java不行。嗯，在這種情況下，我會試著向他解釋我下面給出的第二個原因，它不是因為技術難度,而是更多的可維護和更清晰的設計是驅動因素,雖然這只能由Java言語設計師確認，我們只是推測。維基百科鏈接有一些很好的解釋，說明在使用多重繼承時，由于鉆石問題，不同的語言地址問題是如何產生的。

　　2)對我來說第二個也是更有說服力的理由是，多重繼承確實使設計復雜化并在轉換、構造函數鏈接等過程中產生問題。假設你需要多重繼承的情況并不多，簡單起見，明智的決定是省略它。此外，Java可以通過使用接口支持單繼承來避免這種歧義。由于接口只有方法聲明而且沒有提供任何實現，因此只有一個特定方法的實現，因此不會有任何歧義。（實用詳盡的Java面試題大全，可以在Java知音公眾號回復“面試題聚合”）

　　為什么Java不支持運算符重載？

　　另一個類似棘手的Java問題。為什么C++支持運算符重載而Java不支持?有人可能會說+運算符在Java中已被重載用于字符串連接，不要被這些論據所欺騙。

　　與C++不同，Java不支持運算符重載。Java不能為程序員提供自由的標準算術運算符重載，例如+，-，*和/等。如果你以前用過C++，那么Java與C++相比少了很多功能，例如Java不支持多重繼承，Java中沒有指針，Java中沒有引用傳遞。另一個類似的問題是關于Java通過引用傳遞，這主要表現為Java是通過值還是引用傳參。雖然我不知道背后的真正原因，但我認為以下說法有些道理，為什么Java不支持運算符重載。

　　1)簡單性和清晰性。清晰性是Java設計者的目標之一。設計者不是只想復制語言，而是希望擁有一種清晰，真正面向對象的語言。添加運算符重載比沒有它肯定會使設計更復雜，并且它可能導致更復雜的編譯器,或減慢JVM，因為它需要做額外的工作來識別運算符的實際含義，并減少優化的機會,以保證Java中運算符的行為。

　　2)避免編程錯誤。Java不允許用戶定義的運算符重載，因為如果允許程序員進行運算符重載，將為同一運算符賦予多種含義，這將使任何開發人員的學習曲線變得陡峭，事情變得更加混亂。據觀察，當語言支持運算符重載時，編程錯誤會增加，從而增加了開發和交付時間。由于Java和JVM已經承擔了大多數開發人員的責任，如在通過提供垃圾收集器進行內存管理時，因為這個功能增加污染代碼的機會,成為編程錯誤之源,因此沒有多大意義。

　　3)JVM復雜性。從JVM的角度來看，支持運算符重載使問題變得更加困難。通過更直觀，更干凈的方式使用方法重載也能實現同樣的事情，因此不支持Java中的運算符重載是有意義的。與相對簡單的JVM相比，復雜的JVM可能導致JVM更慢，并為保證在Java中運算符行為的確定性從而減少了優化代碼的機會。

　　4)讓開發工具處理更容易。這是在Java中不支持運算符重載的另一個好處。省略運算符重載使語言更容易處理，這反過來又更容易開發處理語言的工具，例如IDE或重構工具。Java中的重構工具遠勝于C++。

　　為什么String在Java中是不可變的？

　　我最喜歡的Java面試問題，很棘手，但同時也非常有用。一些面試者也常問這個問題，為什么String在Java中是final的。

　　字符串在Java中是不可變的，因為String對象緩存在String池中。由于緩存的字符串在多個客戶之間共享，因此始終存在風險，其中一個客戶的操作會影響所有其他客戶。例如，如果一段代碼將String“Test”的值更改為“TEST”，則所有其他客戶也將看到該值。由于String對象的緩存性能是很重要的一方面，因此通過使String類不可變來避免這種風險。

　　同時，String是final的，因此沒有人可以通過擴展和覆蓋行為來破壞String類的不變性、緩存、散列值的計算等。String類不可變的另一個原因可能是由于HashMap。

　　由于把字符串作為HashMap鍵很受歡迎。對于鍵值來說，重要的是它們是不可變的，以便用它們檢索存儲在HashMap中的值對象。由于HashMap的工作原理是散列，因此需要具有相同的值才能正常運行。如果在插入后修改了String的內容，可變的String將在插入和檢索時生成兩個不同的哈希碼，可能會丟失Map中的值對象。

　　如果你是印度板球迷，你可能能夠與我的下一句話聯系起來。字符串是Java的VVSLaxman，即非常特殊的類。我還沒有看到一個沒有使用String編寫的Java程序。這就是為什么對String的充分理解對于Java開發人員來說非常重要。

　　String作為數據類型，傳輸對象和中間人角色的重要性和流行性也使這個問題在Java面試中很常見。

　　為什么String在Java中是不可變的是Java中最常被問到的字符串訪問問題之一，它首先討論了什么是String，Java中的String如何與C和C++中的String不同，然后轉向在Java中什么是不可變對象，不可變對象有什么好處，為什么要使用它們以及應該使用哪些場景。

　　這個問題有時也會問：“為什么String在Java中是final的”。在類似的說明中，如果你正在準備Java面試，我建議你看看《Java程序員面試寶典(第4版)》，這是高級和中級Java程序員的優秀資源。它包含來自所有重要Java主題的問題，包括多線程，集合，GC，JVM內部以及Spring和Hibernate框架等。

　　正如我所說，這個問題可能有很多可能的答案，而String類的唯一設計者可以放心地回答它。我在JoshuaBloch的EffectiveJava書中期待一些線索，但他也沒有提到它。我認為以下幾點解釋了為什么String類在Java中是不可變的或final的：

　　1)想象字符串池沒有使字符串不可變，它根本不可能，因為在字符串池的情況下，一個字符串對象/文字，例如“Test”已被許多參考變量引用，因此如果其中任何一個更改了值，其他參數將自動受到影響，即假設

　　StringA="Test";

　　StringB="Test";

　　現在字符串B調用"Test".toUpperCase(),將同一個對象改為“TEST”，所以A也是“TEST”，這不是期望的結果。

　　下圖顯示了如何在堆內存和字符串池中創建字符串。

　　2)字符串已被廣泛用作許多Java類的參數，例如，為了打開網絡連接，你可以將主機名和端口號作為字符串傳遞，你可以將數據庫URL作為字符串傳遞,以打開數據庫連接，你可以通過將文件名作為參數傳遞給FileI/O類來打開Java中的任何文件。如果String不是不可變的，這將導致嚴重的安全威脅，我的意思是有人可以訪問他有權授權的任何文件，然后可以故意或意外地更改文件名并獲得對該文件的訪問權限。由于不變性，你無需擔心這種威脅。這個原因也說明了，為什么String在Java中是最終的，通過使java.lang.Stringfinal，Java設計者確保沒有人覆蓋String類的任何行為。

　　3)由于String是不可變的，它可以安全地共享許多線程，這對于多線程編程非常重要.并且避免了Java中的同步問題，不變性也使得String實例在Java中是線程安全的，這意味著你不需要從外部同步String操作。關于String的另一個要點是由截取字符串SubString引起的內存泄漏，這不是與線程相關的問題，但也是需要注意的。

　　4)為什么String在Java中是不可變的另一個原因是允許String緩存其哈希碼，Java中的不可變String緩存其哈希碼，并且不會在每次調用String的hashcode方法時重新計算，這使得它在Java中的HashMap中使用的HashMap鍵非常快。簡而言之，因為String是不可變的，所以沒有人可以在創建后更改其內容，這保證了String的hashCode在多次調用時是相同的。

　　5)String不可變的絕對最重要的原因是它被類加載機制使用，因此具有深刻和基本的安全考慮。如果String是可變的，加載“java.io.Writer”的請求可能已被更改為加載“mil.vogoon.DiskErasingWriter”.安全性和字符串池是使字符串不可變的主要原因。順便說一句，上面的理由很好回答另一個Java面試問題:“為什么String在Java中是最終的”。要想是不可變的，你必須是最終的，這樣你的子類不會破壞不變性。你怎么看？

　   以上就是動力節點Java培訓機構小編介紹的“2020年Java程序員面試題目”的內容，希望對大家有幫助，如有疑問，請在線咨詢，有專業老師隨時為你服務。