java平臺的理解

• 談?wù)勀銓?Java 平臺的理解？“Java 是解釋執(zhí)行”，這句話正確么？

  • Java本身是一種面向?qū)ο蟮恼Z音，最顯著的特性有兩個方面，一個是所謂的“書寫一次，到處運行”（Write once,run anywhere），能夠非常容易地獲得跨平臺能力；另一個就是垃圾收集（GC，Garbage Collection）

  • Java源代碼，首先通過Javac編譯成字節(jié)碼（bytecode），然后在運行時，通過Java虛擬機內(nèi)嵌的解釋器將字節(jié)碼轉(zhuǎn)換為最終的機器碼。但是常見的JVM，比如我們大多數(shù)情況下使用的Oracle JDK提供的Hotspot JVM,都提供了JIT(Just-In-Time)編譯器，也就是常說的動態(tài)編譯器，JIT能夠在運行時將熱點代碼編譯成機器碼，這種情況下部分熱點代碼就屬于編譯執(zhí)行，而不是解釋執(zhí)行了。Javac的編譯，編譯Java源碼生成“.class”文件里面實際是字節(jié)碼，而不是可以直接執(zhí)行的機器碼。Java通過字節(jié)碼和JVM這種跨平臺的抽象，屏蔽了操作系統(tǒng)和硬件的細節(jié)，這也是實現(xiàn)“一次編譯，到處運行”的基礎(chǔ)。

Exception和Error有什么區(qū)別？

• throwable下分為error和exception

• 常見的error: OutofMemoryError,StackOveFlowError,NoClassDefFoundError,

• exception：NullPointerException,runtimeException,classCastException等

• 實際開發(fā)中異常處理的兩個原則：

  • 盡量不要捕獲類似 Exception 這樣的通用異常，而是應(yīng)該捕獲特定異常

  • 不要生吞（swallow）異常這是異常處理中要特別注意的事情，因為很可能會導(dǎo)致非常難以診斷的詭異情況

    • 生吞異常，往往是基于假設(shè)這段代碼可能不會發(fā)生，或者感覺忽略異常是無所謂的，但是千萬不要在產(chǎn)品代碼做這種假設(shè)

  • Throw early, catch late 原則

    public void readPreferences(String filename) {Objects. requireNonNull(filename);//...perform other operations... InputStream in = new FileInputStream(filename);//...read the preferences file... }

強引用、軟引用、弱引用、幻象引用有什么區(qū)別？具體使用場景是什么..

• 強引用：強引用，是我們最常見的普通對象引用，只要還有強引用指向一個對象，就能表明對象還活著，垃圾收集器不會碰這種對象。

• 軟引用：是一種相對強引用弱化一些的引用，可以讓對象豁免一些垃圾收集，只有當(dāng)JVM認為內(nèi)存不足時，才會去試圖回收軟引用指向的對象。軟引用通常用來實現(xiàn)內(nèi)存敏感的緩存，如果還有空閑內(nèi)存，就可以暫時保留緩存，當(dāng)內(nèi)存不足時清理掉，這樣就保證了使用緩存的同時，不會耗盡內(nèi)存。軟引用可以和一個引用隊列（ReferenceQueue）聯(lián)合使用，如果軟引用所引用的對象被垃圾回收器回收，Java虛擬機就會把這個軟引用加入到與之關(guān)聯(lián)的引用隊列中。后續(xù)，我們可以調(diào)用ReferenceQueue的poll()方法來檢查是否有它所關(guān)心的對象被回收。如果隊列為空，將返回一個null,否則該方法返回隊列中前面的一個Reference對象

• 弱引用：并不能使對象豁免垃圾收集，僅僅是提供一種訪問在弱引用狀態(tài)下對象的途徑。這就可以用來構(gòu)建一種沒有特定約束的關(guān)系，比如，維護一種非強制性的映射關(guān)系，如果試圖獲取時對象還在，就使用它，否則重新實例化。它同樣是很多緩存實現(xiàn)的選擇

• 虛引用：幻象引用，也叫虛引用，不能通過它來訪問對象，用幻象引用監(jiān)控對象的創(chuàng)建和銷毀

• 對象可達性狀態(tài)流轉(zhuǎn)分析：

String、StringBuffer、StringBuilder有什么區(qū)別？

• String 是 Java 語言非常基礎(chǔ)和重要的類，提供了構(gòu)造和管理字符串的各種基本邏輯。它是典型的 Immutable 類，被聲明成為 final class，所有屬性也都是 final 的。也由于它的不可變性，類似拼接、裁剪字符串等動作，都會產(chǎn)生新的 String 對象。由于字符串操作的普遍性，所以相關(guān)操作的效率往往對應(yīng)用性能有明顯影響

• StringBuffer 本質(zhì)是一個線程安全的可修改字符序列，它保證了線程安全，也隨之帶來了額外的性能開銷。如果沒有線程安全的需要，推薦使用它的后繼者，也就是 StringBuilder。

• 字符串的設(shè)計和實現(xiàn)考量：StringBuffer 和 StringBuilder 底層都是利用可修改的（char，JDK 9 以后是 byte）數(shù)組，二者都繼承了 AbstractStringBuilder，里面包含了基本操作，區(qū)別僅在于最終的方法是否加了 synchronized。目前的實現(xiàn)是，構(gòu)建時初始字符串長度加 16，如果沒有構(gòu)建對象時輸入最初的字符串，那么初始值就是 16。

• String的演化：Java 的字符串在歷史版本中使用 char 數(shù)組來存數(shù)據(jù)的，Java 中的 char 是兩個 bytes 大小，拉丁語系語言的字符，根本就不需要太寬的 char，這樣無區(qū)別的實現(xiàn)就造成了一定的浪費。密度是編程語言平臺永恒的話題，因為歸根結(jié)底絕大部分任務(wù)是要來操作數(shù)據(jù)的。Java 9 中，我們引入了 Compact Strings 的設(shè)計，對字符串進行了大刀闊斧的改進。將數(shù)據(jù)存儲方式從 char 數(shù)組，改變?yōu)橐粋€ byte 數(shù)組加上一個標識編碼的所謂 coder，并且將相關(guān)字符串操作類都進行了修改。另外，所有相關(guān)的 Intrinsic 之類也都進行了重寫，以保證沒有任何性能損失。緊湊字符串帶來的優(yōu)勢，即更小的內(nèi)存占用、更快的操作速度。

• 很多字符串操作，比如 getBytes()/String(byte[] bytes) 等都是隱含著使用平臺默認編碼，這是一種好的實踐嗎？是否有利于避免亂碼？

  getBytes和String相關(guān)的轉(zhuǎn)換時根據(jù)業(yè)務(wù)需要建議指定編碼方式，如果不指定則看看JVM參數(shù)里有沒有指定file.encoding參數(shù)，如果JVM沒有指定，那使用的默認編碼就是運行的操作系統(tǒng)環(huán)境的編碼了，那這個編碼就變得不確定了。常見的編碼iso8859-1是單字節(jié)編碼，UTF-8是變長的編碼。

動態(tài)代理是基于什么原理？

• 反射，它就像是一種魔法，引入運行時自省能力，賦予了 Java 語言令人意外的活力，通過運行時操作元數(shù)據(jù)或?qū)ο?#xff0c;Java 可以靈活地操作運行時才能確定的信息。而動態(tài)代理，則是延伸出來的一種廣泛應(yīng)用于產(chǎn)品開發(fā)中的技術(shù)，很多繁瑣的重復(fù)編程，都可以被動態(tài)代理機制優(yōu)雅地解決

• 動態(tài)代理應(yīng)用非常廣泛，雖然最初多是因為 RPC 等使用進入我們視線，但是動態(tài)代理的使用場景遠遠不僅如此，它完美符合 Spring AOP 等切面編程。我在后面的專欄還會進一步詳細分析 AOP 的目的和能力。簡單來說它可以看作是對 OOP 的一個補充，因為 OOP 對于跨越不同對象或類的分散、糾纏邏輯表現(xiàn)力不夠，比如在不同模塊的特定階段做一些事情，類似日志、用戶鑒權(quán)、全局性異常處理、性能監(jiān)控，甚至事務(wù)處理等，你可以參考下面這張圖

• AOP 通過（動態(tài)）代理機制可以讓開發(fā)者從這些繁瑣事項中抽身出來，大幅度提高了代碼的抽象程度和復(fù)用度。從邏輯上來說，我們在軟件設(shè)計和實現(xiàn)中的類似代理，如 Facade、Observer 等很多設(shè)計目的，都可以通過動態(tài)代理優(yōu)雅地實現(xiàn)。

int和Integer有什么區(qū)別

• 自動裝箱 / 自動拆箱是發(fā)生在什么階段？

  • 自動裝箱實際上算是一種語法糖.Java 平臺為我們自動進行了一些轉(zhuǎn)換，保證不同的寫法在運行時等價，它們發(fā)生在編譯階段，也就是生成的字節(jié)碼是一致的

  • 自動裝箱 / 自動拆箱似乎很酷，在編程實踐中，有什么需要注意的嗎？

    • 原則上，建議避免無意中的裝箱、拆箱行為，尤其是在性能敏感的場合，創(chuàng)建 10 萬個 Java 對象和 10 萬個整數(shù)的開銷可不是一個數(shù)量級的，不管是內(nèi)存使用還是處理速度，光是對象頭的空間占用就已經(jīng)是數(shù)量級的差距了

    • 擴展：使用原始數(shù)據(jù)類型、數(shù)組甚至本地代碼實現(xiàn)等，在性能極度敏感的場景往往具有比較大的優(yōu)勢，用其替換掉包裝類、動態(tài)數(shù)組（如 ArrayList）等可以作為性能優(yōu)化的備選項。一些追求極致性能的產(chǎn)品或者類庫，會極力避免創(chuàng)建過多對象。當(dāng)然，在大多數(shù)產(chǎn)品代碼里，并沒有必要這么做，還是以開發(fā)效率優(yōu)先

對比Vector、ArrayList、LinkedList有何區(qū)別？

• Vector 是 Java 早期提供的線程安全的動態(tài)數(shù)組，如果不需要線程安全，并不建議選擇，畢竟同步是有額外開銷的。Vector 內(nèi)部是使用對象數(shù)組來保存數(shù)據(jù)，可以根據(jù)需要自動的增加容量，當(dāng)數(shù)組已滿時，會創(chuàng)建新的數(shù)組，并拷貝原有數(shù)組數(shù)據(jù)

• ArrayList 是應(yīng)用更加廣泛的動態(tài)數(shù)組實現(xiàn)，它本身不是線程安全的，所以性能要好很多。與 Vector 近似，ArrayList 也是可以根據(jù)需要調(diào)整容量，不過兩者的調(diào)整邏輯有所區(qū)別，Vector 在擴容時會提高 1 倍，而 ArrayList 則是增加 50%

• LinkedList 顧名思義是 Java 提供的雙向鏈表，所以它不需要像上面兩種那樣調(diào)整容量，它也不是線程安全的

  • 也可以補充一下不同容器類型適合的場景：

    • Vector 和 ArrayList 作為動態(tài)數(shù)組，其內(nèi)部元素以數(shù)組形式順序存儲的，所以非常適合隨機訪問的場合。除了尾部插入和刪除元素，往往性能會相對較差，比如我們在中間位置插入一個元素，需要移動后續(xù)所有元素。

    • 而 LinkedList 進行節(jié)點插入、刪除卻要高效得多，但是隨機訪問性能則要比動態(tài)數(shù)組慢

  • 在應(yīng)用開發(fā)中，如果事先可以估計到，應(yīng)用操作是偏向于插入、刪除，還是隨機訪問較多，就可以針對性的進行選擇

  • 在 Java 8 之中，Java 平臺支持了 Lambda 和 Stream，相應(yīng)的 Java 集合框架也進行了大范圍的增強，以支持類似為集合創(chuàng)建相應(yīng) stream 或者 parallelStream 的方法實現(xiàn)，我們可以非常方便的實現(xiàn)函數(shù)式代碼。在 Java 9 中，Java 標準類庫提供了一系列的靜態(tài)工廠方法，比如，List.of()、Set.of()，大大簡化了構(gòu)建小的容器實例的代碼量

    ? ArrayList<String> ?list = new ArrayList<>();list.add("Hello");list.add("World"); //利用新的容器靜態(tài)工廠方法 List<String> simpleList = List.of("Hello","world");

對比Hashtable、HashMap、TreeMap有什么不同？

• Hashtable 是早期 Java 類庫提供的一個哈希表實現(xiàn)，本身是同步的，不支持 null 鍵和值，由于同步導(dǎo)致的性能開銷，所以已經(jīng)很少被推薦使用。

• HashMap 是應(yīng)用更加廣泛的哈希表實現(xiàn)，行為上大致上與 HashTable 一致，主要區(qū)別在于 HashMap 不是同步的，支持 null 鍵和值等。通常情況下，HashMap 進行 put 或者 get 操作，可以達到常數(shù)時間的性能，所以它是絕大部分利用鍵值對存取場景的首選

• TreeMap 則是基于紅黑樹的一種提供順序訪問的 Map，和 HashMap 不同，它的 get、put、remove 之類操作都是 O（log(n)）的時間復(fù)雜度，具體順序可以由指定的 Comparator 來決定，或者根據(jù)鍵的自然順序來判斷。

• hashmap擴容時為什么這里需要將高位數(shù)據(jù)移位到低位進行異或運算呢？

  • 這是因為有些數(shù)據(jù)計算出的哈希值差異主要在高位，而 HashMap 里的哈希尋址是忽略容量以上的高位的，那么這種處理就可以有效避免類似情況下的哈希碰撞

• 為什么 HashMap 要樹化呢？

  • 本質(zhì)上這是個安全問題。因為在元素放置過程中，如果一個對象哈希沖突，都被放置到同一個桶里，則會形成一個鏈表，我們知道鏈表查詢是線性的，會嚴重影響存取的性能。

    而在現(xiàn)實世界，構(gòu)造哈希沖突的數(shù)據(jù)并不是非常復(fù)雜的事情，惡意代碼就可以利用這些數(shù)據(jù)大量與服務(wù)器端交互，導(dǎo)致服務(wù)器端 CPU 大量占用，這就構(gòu)成了哈希碰撞拒絕服務(wù)攻擊，國內(nèi)一線互聯(lián)網(wǎng)公司就發(fā)生過類似攻擊事件

  • 解決哈希沖突的常用方法有:

    • 開放定址：當(dāng)關(guān)鍵字key的哈希地址p=H（key）出現(xiàn)沖突時，以p為基礎(chǔ)，產(chǎn)生另一個哈希地址p1，如果p1仍然沖突，再以p為基礎(chǔ)，產(chǎn)生另一個哈希地址p2，…，直到找出一個不沖突的哈希地址pi ，將相應(yīng)元素存入其中。

    • 再哈希法：這種方法是同時構(gòu)造多個不同的哈希函數(shù)：

      Hi=RH1（key） i=1，2，…，k當(dāng)哈希地址Hi=RH1（key）發(fā)生沖突時，再計算Hi=RH2（key）……，直到?jīng)_突不再產(chǎn)生。這種方法不易產(chǎn)生聚集，但增加了計算時間。

    • 鏈地址：這種方法的基本思想是將所有哈希地址為i的元素構(gòu)成一個稱為同義詞鏈的單鏈表，并將單鏈表的頭指針存在哈希表的第i個單元中，因而查找、插入和刪除主要在同義詞鏈中進行。鏈地址法適用于經(jīng)常進行插入和刪除的情況。

ConcurrentHashMap如何實現(xiàn)高效地線程安全？

• Java 提供了不同層面的線程安全支持。在傳統(tǒng)集合框架內(nèi)部，除了 Hashtable 等同步容器，還提供了所謂的同步包裝器（Synchronized Wrapper），我們可以調(diào)用 Collections 工具類提供的包裝方法，來獲取一個同步的包裝容器（如 Collections.synchronizedMap），但是它們都是利用非常粗粒度的同步方式，在高并發(fā)情況下，性能比較低下。

  另外，更加普遍的選擇是利用并發(fā)包提供的線程安全容器類，它提供了：

  • 各種并發(fā)容器，比如 ConcurrentHashMap、CopyOnWriteArrayList。

  • 各種線程安全隊列（Queue/Deque），如 ArrayBlockingQueue、SynchronousQueue。

  • 各種有序容器的線程安全版本等。

  具體保證線程安全的方式，包括有從簡單的 synchronize 方式，到基于更加精細化的，比如基于分離鎖實現(xiàn)的 ConcurrentHashMap 等并發(fā)實現(xiàn)等。具體選擇要看開發(fā)的場景需求，總體來說，并發(fā)包內(nèi)提供的容器通用場景，遠優(yōu)于早期的簡單同步實現(xiàn)。

• 為什么需要 ConcurrentHashMap？

  • Hashtable 本身比較低效，因為它的實現(xiàn)基本就是將 put、get、size 等各種方法加上“synchronized”。簡單來說，這就導(dǎo)致了所有并發(fā)操作都要競爭同一把鎖，一個線程在進行同步操作時，其他線程只能等待，大大降低了并發(fā)操作的效率

  • Collections 提供的同步包裝器：只是利用輸入 Map 構(gòu)造了另一個同步版本，所有操作雖然不再聲明成為 synchronized 方法，但是還是利用了“this”作為互斥的 mutex，沒有真正意義上的改進！

  • 構(gòu)造的時候，Segment 的數(shù)量由所謂的 concurrentcyLevel 決定，默認是 16

  • 在JDK1.7中，ConcurrentHashMap采用Segment + HashEntry的方式進行實現(xiàn)，結(jié)構(gòu)如下：

    一個 ConcurrentHashMap 里包含一個 Segment 數(shù)組。Segment 的結(jié)構(gòu)和HashMap類似，是一種數(shù)組和鏈表結(jié)構(gòu)，一個 Segment 包含一個 HashEntry 數(shù)組，每個 HashEntry 是一個鏈表結(jié)構(gòu)的元素，每個 Segment 守護著一個HashEntry數(shù)組里的元素，當(dāng)對 HashEntry 數(shù)組的數(shù)據(jù)進行修改時，必須首先獲得對應(yīng)的 Segment的鎖。 ———————————————— 版權(quán)聲明：本文為CSDN博主「Java程序員-張凱」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接及本聲明。 原文鏈接：https://blog.csdn.net/qq_41701956/article/details/110119625

  • 在JDK1.8中，放棄了Segment臃腫的設(shè)計，取而代之的是采用Node + CAS + Synchronized來保證并發(fā)安全進行實現(xiàn)，synchronized只鎖定當(dāng)前鏈表或紅黑二叉樹的首節(jié)點，這樣只要hash不沖突，就不會產(chǎn)生并發(fā)，效率又提升N倍。

Java提供了哪些IO方式？ NIO如何實現(xiàn)多路復(fù)用？

• javaio分為：同步阻塞IO，在讀取輸入流或者寫入輸出流時，在讀、寫動作完成之前，線程會一直阻塞在那里，它們之間的調(diào)用是可靠的線性順序。

  • 優(yōu)點：代碼比較簡單、直觀，

  • 缺點則是 IO 效率和擴展性存在局限性，容易成為應(yīng)用性能的瓶頸。

• java1.4引入了NIO框架，提供了Channel、Selector、Buffer等抽象，構(gòu)建多路復(fù)用的、同步非阻塞 IO 程序，同時提供了更接近操作系統(tǒng)底層的高性能數(shù)據(jù)操作方式。

• java7中引入了AIO，異步非阻塞 IO 方式。基于事件和回調(diào)機制。應(yīng)用操作直接返回，而不會阻塞在那里，當(dāng)后臺處理完成，操作系統(tǒng)會通知相應(yīng)線程進行后續(xù)工作。

• BIO、NIO、NIO 2（AIO）

  • 基礎(chǔ) API 功能與設(shè)計， InputStream/OutputStream 和 Reader/Writer 的關(guān)系和區(qū)別。

  • NIO、NI

  • O 2 的基本組成。

  • 給定場景，分別用不同模型實現(xiàn)，分析 BIO、NIO 等模式的設(shè)計和實現(xiàn)原理。

  • NIO 提供的高性能數(shù)據(jù)操作方式是基于什么原理，如何使用？

  • 或者，從開發(fā)者的角度來看，你覺得 NIO 自身實現(xiàn)存在哪些問題？有什么改進的想法嗎？

• 概念：區(qū)分同步或異步（synchronous/asynchronous）。簡單來說，同步是一種可靠的有序運行機制，當(dāng)我們進行同步操作時，后續(xù)的任務(wù)是等待當(dāng)前調(diào)用返回，才會進行下一步；而異步則相反，其他任務(wù)不需要等待當(dāng)前調(diào)用返回，通常依靠事件、回調(diào)等機制來實現(xiàn)任務(wù)間次序關(guān)系。

• 區(qū)分阻塞與非阻塞（blocking/non-blocking）。在進行阻塞操作時，當(dāng)前線程會處于阻塞狀態(tài)，無法從事其他任務(wù)，只有當(dāng)條件就緒才能繼續(xù)，比如 ServerSocket 新連接建立完畢，或數(shù)據(jù)讀取、寫入操作完成；而非阻塞則是不管 IO 操作是否結(jié)束，直接返回，相應(yīng)操作在后臺繼續(xù)處理。

  • IO 不僅僅是對文件的操作，網(wǎng)絡(luò)編程中，比如 Socket 通信，都是典型的 IO 操作目標。

  • 輸入流、輸出流（InputStream/OutputStream）是用于讀取或?qū)懭胱止?jié)的，例如操作圖片文件。

  • 而 Reader/Writer 則是用于操作字符，增加了字符編解碼等功能，適用于類似從文件中讀取或者寫入文本信息。本質(zhì)上計算機操作的都是字節(jié)，不管是網(wǎng)絡(luò)通信還是文件讀取，Reader/Writer 相當(dāng)于構(gòu)建了應(yīng)用邏輯和原始數(shù)據(jù)之間的橋梁。

  • BufferedOutputStream 等帶緩沖區(qū)的實現(xiàn)，可以避免頻繁的磁盤讀寫，進而提高 IO 處理效率。這種設(shè)計利用了緩沖區(qū)，將批量數(shù)據(jù)進行一次操作，但在使用中千萬別忘了 flush。

• Java NIO 概覽

  首先，熟悉一下 NIO 的主要組成部分：

  • Buffer，高效的數(shù)據(jù)容器，除了布爾類型，所有原始數(shù)據(jù)類型都有相應(yīng)的 Buffer 實現(xiàn)。

  • Channel，類似在 Linux 之類操作系統(tǒng)上看到的文件描述符，是 NIO 中被用來支持批量式 IO 操作的一種抽象。

  File 或者 Socket，通常被認為是比較高層次的抽象，而 Channel 則是更加操作系統(tǒng)底層的一種抽象，這也使得 NIO 得以充分利用現(xiàn)代操作系統(tǒng)底層機制，獲得特定場景的性能優(yōu)化，例如，DMA（Direct Memory Access）等。不同層次的抽象是相互關(guān)聯(lián)的，我們可以通過 Socket 獲取 Channel，反之亦然。

  • Selector，是 NIO 實現(xiàn)多路復(fù)用的基礎(chǔ)，它提供了一種高效的機制，可以檢測到注冊在 Selector 上的多個 Channel 中，是否有 Channel 處于就緒狀態(tài)，進而實現(xiàn)了單線程對多 Channel 的高效管理。

  • Chartset，提供 Unicode 字符串定義，NIO 也提供了相應(yīng)的編解碼器等，例如，通過下面的方式進行字符串到 ByteBuffer 的轉(zhuǎn)換

• NIO能解決什么問題

  • 場景：

    ? public class DemoServer extends Thread {private ServerSocket serverSocket;public int getPort() {return ?serverSocket.getLocalPort();}public void run() {try {serverSocket = new ServerSocket(0);while (true) {Socket socket = serverSocket.accept();RequestHandler requestHandler = new RequestHandler(socket);requestHandler.start();}} catch (IOException e) {e.printStackTrace();} finally {if (serverSocket != null) {try {serverSocket.close();} catch (IOException e) {e.printStackTrace();};}}}public static void main(String[] args) throws IOException {DemoServer server = new DemoServer();server.start();try (Socket client = new Socket(InetAddress.getLocalHost(), server.getPort())) {BufferedReader bufferedReader = new BufferedReader(new ? ? ? ? ? ? ? ? ? InputStreamReader(client.getInputStream()));bufferedReader.lines().forEach(s -> System.out.println(s));}}} // 簡化實現(xiàn)，不做讀取，直接發(fā)送字符串 class RequestHandler extends Thread {private Socket socket;RequestHandler(Socket socket) {this.socket = socket;}@Overridepublic void run() {try (PrintWriter out = new PrintWriter(socket.getOutputStream());) {out.println("Hello world!");out.flush();} catch (Exception e) {e.printStackTrace();}}} ?

    • 稍微修正一下這個問題，我們引入線程池機制來避免浪費

      ? serverSocket = new ServerSocket(0); executor = Executors.newFixedThreadPool(8);while (true) {Socket socket = serverSocket.accept();RequestHandler requestHandler = new RequestHandler(socket);executor.execute(requestHandler); }

      如果連接數(shù)并不是非常多，只有最多幾百個連接的普通應(yīng)用，這種模式往往可以工作的很好。但是，如果連接數(shù)量急劇上升，這種實現(xiàn)方式就無法很好地工作了，因為線程上下文切換開銷會在高并發(fā)時變得很明顯，這是同步阻塞方式的低擴展性劣勢.

      NIO 則是利用了單線程輪詢事件的機制，通過高效地定位就緒的 Channel，來決定做什么，僅僅 select 階段是阻塞的，可以有效避免大量客戶端連接時，頻繁線程切換帶來的問題，應(yīng)用的擴展能力有了非常大的提高

    • NIO 引入的多路復(fù)用機制，提供了另外一種思路

      public class NIOServer extends Thread {public void run() {try (Selector selector = Selector.open();ServerSocketChannel serverSocket = ServerSocketChannel.open();) {// 創(chuàng)建 Selector 和 ChannelserverSocket.bind(new InetSocketAddress(InetAddress.getLocalHost(), 8888));serverSocket.configureBlocking(false);// 注冊到 Selector，并說明關(guān)注點serverSocket.register(selector, SelectionKey.OP_ACCEPT);while (true) {selector.select();// 阻塞等待就緒的 Channel，這是關(guān)鍵點之一Set<SelectionKey> selectedKeys = selector.selectedKeys();Iterator<SelectionKey> iter = selectedKeys.iterator();while (iter.hasNext()) {SelectionKey key = iter.next();// 生產(chǎn)系統(tǒng)中一般會額外進行就緒狀態(tài)檢查sayHelloWorld((ServerSocketChannel) key.channel());iter.remove();}}} catch (IOException e) {e.printStackTrace();}}private void sayHelloWorld(ServerSocketChannel server) throws IOException {try (SocketChannel client = server.accept();) { ? ? ? ? ?client.write(Charset.defaultCharset().encode("Hello world!"));}}// 省略了與前面類似的 main }

      • 在 Java 7 引入的 NIO 2 中，又增添了一種額外的異步 IO 模式，利用事件和回調(diào)，處理 Accept、Read 等操作。 AIO 實現(xiàn)看起來是類似這樣子：

      AsynchronousServerSocketChannel serverSock = ? ? ? ?AsynchronousServerSocketChannel.open().bind(sockAddr); serverSock.accept(serverSock, new CompletionHandler<>() { // 為異步操作指定 CompletionHandler 回調(diào)函數(shù)@Overridepublic void completed(AsynchronousSocketChannel sockChannel, AsynchronousServerSocketChannel serverSock) {serverSock.accept(serverSock, this);// 另外一個 write（sock，CompletionHandler{}）sayHelloWorld(sockChannel, Charset.defaultCharset().encode("Hello World!"));}// 省略其他路徑處理方法... });

談?wù)劷涌诤统橄箢愑惺裁磪^(qū)別？

• 接口：接口是對行為的抽象，是抽象方法的集合。利用接口可以達到API定義和實現(xiàn)分離的目的。接口，不能實例化；不能包含任何非常量成員，任何 field 都是隱含著 public static final 的意義；同時，沒有非靜態(tài)方法實現(xiàn)，也就是說要么是抽象方法，要么是靜態(tài)方法。實現(xiàn)接口用 implements關(guān)鍵字

• 抽象類：抽象類是不能實例化的類，用 abstract 關(guān)鍵字修飾 class，其目的主要是代碼重用。其他和一般的java類沒有太大區(qū)別，可有一個或者多個抽象方法也可以沒有。用extends關(guān)鍵字繼承。

• Java 不支持多繼承。java可以實現(xiàn)了多個接口，因為接口是抽象方法的集合。在一些情況下存在特定場景，需要抽象出與具體實現(xiàn)、實例化無關(guān)的通用邏輯，或者純調(diào)用關(guān)系的邏輯，但是使用傳統(tǒng)的抽象類會陷入到單繼承的窘境。以往常見的做法是，實現(xiàn)由靜態(tài)方法組成的工具類（Utils），比如 java.util.Collections。

• 為接口添加任何抽象方法，相應(yīng)的所有實現(xiàn)了這個接口的類，也必須實現(xiàn)新增方法，否則會出現(xiàn)編譯錯誤。對于抽象類，如果我們添加非抽象方法，其子類只會享受到能力擴展，而不用擔(dān)心編譯出問題

• 有一類沒有任何方法的接口，通常叫作 Marker Interface，顧名思義，它的目的就是為了聲明某些東西。這類似于注明annotation，對于 Annotation，因為可以指定參數(shù)和值，在表達能力上要更強大一些，所以更多人選擇使用 Annotation。

• Java 8 增加了函數(shù)式編程的支持，所以又增加了一類定義，即所謂 functional interface，簡單說就是只有一個抽象方法的接口，通常建議使用 @FunctionalInterface Annotation 來標記。 Java 8 開始，interface 增加了對 default method 的支持。Java 9 以后，甚至可以定義 private default method.

  public interface Collection<E> extends Iterable<E> {/*** Returns a sequential Stream with this collection as its source* ...**/default Stream<E> stream() {return StreamSupport.stream(spliterator(), false);}}

  進行面向?qū)ο缶幊?#xff0c;掌握基本的設(shè)計原則是必須的，我今天介紹最通用的部分，也就是所謂的 S.O.L.I.D 原則。

• 單一職責(zé)（Single Responsibility），類或者對象最好是只有單一職責(zé)，在程序設(shè)計中如果發(fā)現(xiàn)某個類承擔(dān)著多種義務(wù)，可以考慮進行拆分。

• 開關(guān)原則（Open-Close, Open for extension, close for modification），設(shè)計要對擴展開放，對修改關(guān)閉。換句話說，程序設(shè)計應(yīng)保證平滑的擴展性，盡量避免因為新增同類功能而修改已有實現(xiàn)，這樣可以少產(chǎn)出些回歸（regression）問題。

• 里氏替換（Liskov Substitution），這是面向?qū)ο蟮幕疽刂?#xff0c;進行繼承關(guān)系抽象時，凡是可以用父類或者基類的地方，都可以用子類替換。

• 接口分離（Interface Segregation），我們在進行類和接口設(shè)計時，如果在一個接口里定義了太多方法，其子類很可能面臨兩難，就是只有部分方法對它是有意義的，這就破壞了程序的內(nèi)聚性。 對于這種情況，可以通過拆分成功能單一的多個接口，將行為進行解耦。在未來維護中，如果某個接口設(shè)計有變，不會對使用其他接口的子類構(gòu)成影響。

• 依賴反轉(zhuǎn)（Dependency Inversion），實體應(yīng)該依賴于抽象而不是實現(xiàn)。也就是說高層次模塊，不應(yīng)該依賴于低層次模塊，而是應(yīng)該基于抽象。實踐這一原則是保證產(chǎn)品代碼之間適當(dāng)耦合度的法寶。

synchronized和ReentrantLock有什么區(qū)別呢？

• 鎖作為并發(fā)的基礎(chǔ)工具之一，你至少需要掌握：

  • 理解什么是線程安全。

  • synchronized、ReentrantLock 等機制的基本使用與案例。

• 更近一步，你還需要：

  • 掌握 synchronized、ReentrantLock 底層實現(xiàn)；理解鎖膨脹、降級；理解偏斜鎖、自旋鎖、輕量級鎖、重量級鎖等概念。

  • 掌握并發(fā)包中 java.util.concurrent.lock 各種不同實現(xiàn)和案例分析。

• 線程安全：保證多線程環(huán)境下共享的、可修改的狀態(tài)（數(shù)據(jù)）的正確性

  線程安全需要保證幾個基本特性：

  • 原子性，簡單說就是相關(guān)操作不會中途被其他線程干擾，一般通過同步機制實現(xiàn)。

  • 可見性，是一個線程修改了某個共享變量，其狀態(tài)能夠立即被其他線程知曉，通常被解釋為將線程本地狀態(tài)反映到主內(nèi)存上，volatile 就是負責(zé)保證可見性的。

  • 有序性，是保證線程內(nèi)串行語義，避免指令重排等

在JDk的API里對于join()方法是：

join

public final void join() throws InterruptedException Waits for this thread to die. Throws: InterruptedException - if any thread has interrupted the current thread. The interrupted status of the current thread is cleared when this exception is thrown.

即join()的作用是：“等待該線程終止”，這里需要理解的就是該線程是指的主線程等待子線程的終止。也就是在子線程調(diào)用了join()方法后面的代碼，只有等到子線程結(jié)束了才能執(zhí)行。也就是讓外部線程等待該線程結(jié)束后再繼續(xù)執(zhí)行，如果不調(diào)用join（）方法，則主線程不會等待子線程執(zhí)行完，各執(zhí)行各的。

public class ThreadSafeSample {public int sharedState;public void nonSafeAction() {while (sharedState < 100000) {int former = sharedState++;int latter = sharedState;if (former != latter - 1) {System.out.printf("Observed data race, former is " +former + ", " + "latter is " + latter);}}}public static void main(String[] args) throws InterruptedException {ThreadSafeSample sample = new ThreadSafeSample();Thread threadA = new Thread(){public void run(){sample.nonSafeAction();}};Thread threadB = new Thread(){public void run(){sample.nonSafeAction();}};threadA.start();threadB.start();threadA.join();threadB.join();} }

synchronized底層如何實現(xiàn)？什么是鎖的升級、降級？

• synchronized 代碼塊是由一對兒 monitorenter/monitorexit 指令實現(xiàn)的，Monitor 對象是同步的基本實現(xiàn)單元。

  • 在 Java 6 之前，Monitor 的實現(xiàn)完全是依靠操作系統(tǒng)內(nèi)部的互斥鎖，因為需要進行用戶態(tài)到內(nèi)核態(tài)的切換，所以同步操作是一個無差別的重量級操作。

  • 現(xiàn)代的（Oracle）JDK 中，JVM 對此進行了大刀闊斧地改進，提供了三種不同的 Monitor 實現(xiàn)，也就是常說的三種不同的鎖：偏斜鎖（Biased Locking）、輕量級鎖和重量級鎖，大大改進了其性能

    所謂鎖的升級、降級，就是 JVM 優(yōu)化 synchronized 運行的機制，當(dāng) JVM 檢測到不同的競爭狀況時，會自動切換到適合的鎖實現(xiàn)，這種切換就是鎖的升級、降級。

  • synchronized 是 JVM 內(nèi)部的 Intrinsic Lock，所以偏斜鎖、輕量級鎖、重量級鎖的代碼實現(xiàn)，并不在核心類庫部分，而是在 JVM 的代碼中。

  • 線程自身的方法，除了 start，還有個 join 方法（等待線程結(jié)束）；yield 是告訴調(diào)度器，主動讓出 CPU；另外，就是一些已經(jīng)被標記為過時的 resume、stop、suspend 之類，據(jù)我所知，在 JDK 最新版本中，destory/stop 方法將被直接移除。

Spring事務(wù)不起作用 問題匯總

• spring事務(wù)@transactional注解不起作用

總結(jié)

以上是生活随笔為你收集整理的Java核心技术36讲的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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