為什么等待和通知是在 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 問題，因為這個繼承方案的結構類似于菱形，見下圖:

　　A foo()

　　/ \

　　/ \

　　foo() B C foo()

　　\ /

　　\ /

　　D foo()

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

　　2)對我來說第二個也是更有說服力的理由是，多重繼承確實使設計復雜化并在轉換、構造函數鏈接等過程中產生問題。假設你需要多重繼承的情況并不多，簡單起見，明智的決定是省略它。此外，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++。

　　如果你的Serializable類包含一個不可序列化的成員，會發生什么?你是如何解決的?

　　任何序列化該類的嘗試都會因NotSerializableException而失敗，但這可以通過在 Java中 為 static 設置瞬態(trancient)變量來輕松解決。

　　Java 序列化相關的常見問題

　　Java 序列化是一個重要概念, 但它很少用作持久性解決方案, 開發人員大多忽略了 Java 序列化 API。根據我的經驗, Java 序列化在任何 Java核心內容面試中都是一個相當重要的話題, 在幾乎所有的網面試中, 我都遇到過一兩個 Java 序列化問題, 我看過一次面試, 在問幾個關于序列化的問題之后候選人開始感到不自在, 因為缺乏這方面的經驗。

　　他們不知道如何在 Java 中序列化對象, 或者他們不熟悉任何 Java 示例來解釋序列化, 忘記了諸如序列化在 Java 中如何工作, 什么是標記接口, 標記接口的目的是什么, 瞬態變量和可變變量之間的差異, 可序列化接口具有多少種方法, 在 Java 中,Serializable 和 Externalizable 有什么區別, 或者在引入注解之后, 為什么不用 @Serializable 注解或替換 Serializalbe 接口。

　　在本文中,我們將從初學者和高級別進行提問, 這對新手和具有多年 Java 開發經驗的高級開發人員同樣有益。

　　為什么Java中 wait 方法需要在 synchronized 的方法中調用?

　　另一個棘手的核心 Java 問題，wait 和 notify。它們是在有 synchronized 標記的方法或 synchronized 塊中調用的，因為 wait 和 modify 需要監視對其上調用 wait 或 notify-get 的 Object。

　　大多數Java開發人員都知道對象類的 wait()，notify() 和 notifyAll()方法必須在Java中的 synchronized 方法或 synchronized 塊中調用, 但是我們想過多少次, 為什么在 Java 中 wait, notify 和 notifyAll 來自 synchronized 塊或方法?

　　最近這個問題在Java面試中被問到我的一位朋友，他思索了一下，并回答說: 如果我們不從同步上下文中調用 wait() 或 notify() 方法，我們將在 Java 中收到 IllegalMonitorStateException。

　　他的回答從實際效果上年是正確的，但面試官對這樣的答案不會完全滿意，并希望向他解釋這個問題。面試結束后 他和我討論了同樣的問題，我認為他應該告訴面試官關于 Java 中 wait()和 notify()之間的競態條件，如果我們不在同步方法或塊中調用它們就可能存在。

　　讓我們看看競態條件如何在Java程序中發生。它也是流行的線程面試問題之一，并經常在電話和面對面的Java開發人員面試中出現。

　　為什么要等待來自 Java中的 synchronized 方法的 wait方法為什么必須從 Java 中的 synchronized 塊或方法調用 ?我們主要使用 wait()，notify() 或 notifyAll() 方法用于 Java 中的線程間通信。一個線程在檢查條件后正在等待，例如，在經典的生產者 - 消費者問題中，如果緩沖區已滿，則生產者線程等待，并且消費者線程通過使用元素在緩沖區中創建空間后通知生產者線程。調用notify()或notifyAll()方法向單個或多個線程發出一個條件已更改的通知，并且一旦通知線程離開 synchronized 塊，正在等待的所有線程開始獲取正在等待的對象鎖定，幸運的線程在重新獲取鎖之后從 wait() 方法返回并繼續進行。

　　讓我們將整個操作分成幾步，以查看Java中wait()和notify()方法之間的競爭條件的可能性，我們將使用Produce Consumer 線程示例更好地理解方案：

　　Producer 線程測試條件(緩沖區是是否完整)并確認必須等待(找到緩沖區已滿)。

　　Consumer 線程在使用緩沖區中的元素后設置條件。

　　Consumer 線程調用 notify() 方法; 這是不會被聽到的，因為 Producer 線程還沒有等待。

　　Producer 線程調用 wait() 方法并進入等待狀態。

　　因此，由于競態條件，我們可能會丟失通知，如果我們使用緩沖區或只使用一個元素，生產線程將永遠等待，你的程序將掛起。“在java同步中等待 notify 和 notifyall 現在讓我們考慮如何解決這個潛在的競態條件?

　　這個競態條件通過使用 Java 提供的 synchronized 關鍵字和鎖定來解決。為了調用 wait()，notify() 或 notifyAll(), 在Java中，我們必須獲得對我們調用方法的對象的鎖定。由于 Java 中的 wait() 方法在等待之前釋放鎖定并在從 wait() 返回之前重新獲取鎖定方法，我們必須使用這個鎖來確保檢查條件(緩沖區是否已滿)和設置條件(從緩沖區獲取元素)是原子的，這可以通過在 Java 中使用 synchronized 方法或塊來實現。

　　我不確定這是否是面試官實際期待的，但這個我認為至少有意義，請糾正我如果我錯了，請告訴我們是否還有其他令人信服的理由調用 wait()，notify() 或 Java 中的 notifyAll() 方法。

　　總結一下，我們用 Java 中的 synchronized 方法或 synchronized 塊調用 Java 中的 wait()，notify() 或 notifyAll() 方法來避免：

　　1) Java 會拋出 IllegalMonitorStateException，如果我們不調用來自同步上下文的wait()，notify()或者notifyAll()方法。

　　2) Javac 中 wait 和 notify 方法之間的任何潛在競爭條件。

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

相關推薦

最新最全java面試題及答案（初級到高級）

史上最全的中高級JAVA工程師面試題及答案匯總

Java高級開發工程師面試題

2019史上最全java面試題題庫大全800題

哪有資深java工程師面試題