Java 基本功之（三）Java 核心技术
轉載自https://github.com/Snailclimb/JavaGuide/blob/master/docs/java/basis/Java%E5%9F%BA%E7%A1%80%E7%9F%A5%E8%AF%86.md#1121-jvm
Java 核心技術
- 3.1. 反射機制
- 3.1.1.靜態編譯和動態編譯
- 3.1.2.反射機制優缺點
- 3.1.3.反射的應用場景
- 3.2. 異常
- 3.2.1. Java 異常類層次結構圖
- 3.2.2. Throwable 類常用方法
- 3.2.3. try-catch-finally
- 3.2.4. 使用 try-with-resources 來代替try-catch-finally
- 3.3. 多線程
- 3.3.1. 簡述線程、程序、進程的基本概念。以及他們之間關系是什么?（重要）
- 3.3.2. 線程有哪些基本狀態?
- 3.4. 文件與 I\O 流
- 3.4.1. Java 中 IO 流分為幾種?
- 3.4.1.1. 既然有了字節流,為什么還要有字符流?
- 3.4.1.2. BIO,NIO,AIO 有什么區別?
3.1. 反射機制
JAVA 反射機制是在運行狀態中，對于任意一個類，都能夠知道這個類的所有屬性和方法；對于任意一個對象，都能夠調用它的任意一個方法和屬性；這種動態獲取的信息以及動態調用對象的方法的功能稱為 java 語言的反射機制。
3.1.1.靜態編譯和動態編譯
- 靜態編譯： 在編譯時確定類型，綁定對象
- 動態編譯： 運行時確定類型，綁定對象
3.1.2.反射機制優缺點
- 優點： 運行期類型的判斷，動態加載類，提高代碼靈活度。
- 缺點： 1,性能瓶頸：反射相當于一系列解釋操作，通知 JVM 要做的事情，性能比直接的 java 代碼要慢很多。2,安全問題，讓我們可以動態操作改變類的屬性同時也增加了類的安全隱患。
3.1.3.反射的應用場景
反射是框架設計的靈魂。
在我們平時的項目開發過程中，基本上很少會直接使用到反射機制，但這不能說明反射機制沒有用，實際上有很多設計、開發都與反射機制有關，例如模塊化的開發，通過反射去調用對應的字節碼；動態代理設計模式也采用了反射機制，還有我們日常使用的 Spring／Hibernate 等框架也大量使用到了反射機制。
舉例：
3.2. 異常
3.2.1. Java 異常類層次結構圖
圖片來自：https://chercher.tech/java-programming/exceptions-java
在 Java 中，所有的異常都有一個共同的祖先 java.lang 包中的 Throwable 類。Throwable： 有兩個重要的子類：Exception（異常） 和 Error（錯誤） ，二者都是 Java 異常處理的重要子類，各自都包含大量子類。
Error（錯誤）:是程序無法處理的錯誤，表示運行應用程序中較嚴重問題。大多數錯誤與代碼編寫者執行的操作無關，而表示代碼運行時 JVM（Java 虛擬機）出現的問題。例如，Java 虛擬機運行錯誤（Virtual MachineError），當 JVM 不再有繼續執行操作所需的內存資源時，將出現 OutOfMemoryError。這些異常發生時，Java 虛擬機（JVM）一般會選擇線程終止。
這些錯誤表示故障發生于虛擬機自身、或者發生在虛擬機試圖執行應用時，如 Java 虛擬機運行錯誤（Virtual MachineError）、類定義錯誤（NoClassDefFoundError）等。這些錯誤是不可查的，因為它們在應用程序的控制和處理能力之 外，而且絕大多數是程序運行時不允許出現的狀況。對于設計合理的應用程序來說，即使確實發生了錯誤，本質上也不應該試圖去處理它所引起的異常狀況。在 Java 中，錯誤通過 Error 的子類描述。
Exception（異常）:是程序本身可以處理的異常。Exception 類有一個重要的子類 RuntimeException。RuntimeException 異常由 Java 虛擬機拋出。NullPointerException（要訪問的變量沒有引用任何對象時，拋出該異常）、ArithmeticException（算術運算異常，一個整數除以 0 時，拋出該異常）和 ArrayIndexOutOfBoundsException （下標越界異常）。
注意：異常和錯誤的區別：異常能被程序本身處理，錯誤是無法處理。
3.2.2. Throwable 類常用方法
- public string getMessage():返回異常發生時的簡要描述
- public string toString():返回異常發生時的詳細信息
- public string getLocalizedMessage():返回異常對象的本地化信息。使用 Throwable 的子類覆蓋這個方法，可以生成本地化信息。如果子類沒有覆蓋該方法，則該方法返回的信息與 getMessage（）返回的結果相同
- public void printStackTrace():在控制臺上打印 Throwable 對象封裝的異常信息
3.2.3. try-catch-finally
- try 塊： 用于捕獲異常。其后可接零個或多個 catch 塊，如果沒有 - catch 塊，則必須跟一個 finally 塊。
- catch 塊： 用于處理 try 捕獲到的異常。
- finally 塊： 無論是否捕獲或處理異常，finally 塊里的語句都會被執行。當在 try 塊或 catch 塊中遇到 return 語句時，finally 語句塊將在方法返回之前被執行。
在以下 4 種特殊情況下，finally 塊不會被執行：
下面這部分內容來自 issue:https://github.com/Snailclimb/JavaGuide/issues/190。
注意： 當 try 語句和 finally 語句中都有 return 語句時，在方法返回之前，finally 語句的內容將被執行，并且 finally 語句的返回值將會覆蓋原始的返回值。如下：
public class Test {
public static int f(int value) {
try {
return value * value;
} finally {
if (value == 2) {
return 0;
}
}
}
}
如果調用 f(2)，返回值將是 0，因為 finally 語句的返回值覆蓋了 try 語句塊的返回值。
3.2.4. 使用 try-with-resources 來代替try-catch-finally
《Effecitve Java》中明確指出：
面對必須要關閉的資源，我們總是應該優先使用 try-with-resources 而不是try-finally。隨之產生的代碼更簡短，更清晰，產生的異常對我們也更有用。try-with-resources語句讓我們更容易編寫必須要關閉的資源的代碼，若采用try-finally則幾乎做不到這點。
Java 中類似于InputStream、OutputStream 、Scanner 、PrintWriter等的資源都需要我們調用close()方法來手動關閉，一般情況下我們都是通過try-catch-finally語句來實現這個需求，如下：
//讀取文本文件的內容Scanner scanner = null;try {scanner = new Scanner(new File("D://read.txt"));while (scanner.hasNext()) {System.out.println(scanner.nextLine());}} catch (FileNotFoundException e) {e.printStackTrace();} finally {if (scanner != null) {scanner.close();}}使用Java 7之后的 try-with-resources 語句改造上面的代碼:
try (Scanner scanner = new Scanner(new File("test.txt"))) {while (scanner.hasNext()) {System.out.println(scanner.nextLine());} } catch (FileNotFoundException fnfe) {fnfe.printStackTrace(); }當然多個資源需要關閉的時候，使用 try-with-resources 實現起來也非常簡單，如果你還是用try-catch-finally可能會帶來很多問題。
通過使用分號分隔，可以在try-with-resources塊中聲明多個資源。
try (BufferedInputStream bin = new BufferedInputStream(new FileInputStream(new File("test.txt")));BufferedOutputStream bout = new BufferedOutputStream(new FileOutputStream(new File("out.txt")))) {int b;while ((b = bin.read()) != -1) {bout.write(b);}}catch (IOException e) {e.printStackTrace();}3.3. 多線程
3.3.1. 簡述線程、程序、進程的基本概念。以及他們之間關系是什么?（重要）
線程與進程相似，但線程是一個比進程更小的執行單位。一個進程在其執行的過程中可以產生多個線程。與進程不同的是同類的多個線程共享同一塊內存空間和一組系統資源，所以系統在產生一個線程，或是在各個線程之間作切換工作時，負擔要比進程小得多，也正因為如此，線程也被稱為輕量級進程。
程序是含有指令和數據的文件，被存儲在磁盤或其他的數據存儲設備中，也就是說程序是靜態的代碼。
進程是程序的一次執行過程，是系統運行程序的基本單位，因此進程是動態的。系統運行一個程序即是一個進程從創建，運行到消亡的過程。簡單來說，一個進程就是一個執行中的程序，它在計算機中一個指令接著一個指令地執行著，同時，每個進程還占有某些系統資源如 CPU 時間，內存空間，文件，輸入輸出設備的使用權等等。換句話說，當程序在執行時，將會被操作系統載入內存中。 線程是進程劃分成的更小的運行單位。線程和進程最大的不同在于基本上各進程是獨立的，而各線程則不一定，因為同一進程中的線程極有可能會相互影響。從另一角度來說，進程屬于操作系統的范疇，主要是同一段時間內，可以同時執行一個以上的程序，而線程則是在同一程序內幾乎同時執行一個以上的程序段。
3.3.2. 線程有哪些基本狀態?
Java 線程在運行的生命周期中的指定時刻只可能處于下面 6 種不同狀態的其中一個狀態（圖源《Java 并發編程藝術》4.1.4 節）。
Java線程的狀態
線程在生命周期中并不是固定處于某一個狀態而是隨著代碼的執行在不同狀態之間切換。Java 線程狀態變遷如下圖所示（圖源《Java 并發編程藝術》4.1.4 節）：
Java線程狀態變遷
由上圖可以看出：
線程創建之后它將處于 NEW（新建） 狀態，調用 start() 方法后開始運行，線程這時候處于 READY（可運行） 狀態。可運行狀態的線程獲得了 cpu 時間片（timeslice）后就處于 RUNNING（運行） 狀態。
操作系統隱藏 Java 虛擬機（JVM）中的 READY 和 RUNNING 狀態，它只能看到 RUNNABLE 狀態（圖源：HowToDoInJava：Java Thread Life Cycle and Thread States），所以 Java 系統一般將這兩個狀態統稱為 RUNNABLE（運行中） 狀態 。RUNNABLE-VS-RUNNING
當線程執行 wait()方法之后，線程進入 WAITING（等待） 狀態。進入等待狀態的線程需要依靠其他線程的通知才能夠返回到運行狀態，而 TIME_WAITING(超時等待) 狀態相當于在等待狀態的基礎上增加了超時限制，比如通過 sleep（long millis）方法或 wait（long millis）方法可以將 Java 線程置于 TIMED WAITING 狀態。當超時時間到達后 Java 線程將會返回到 RUNNABLE 狀態。當線程調用同步方法時，在沒有獲取到鎖的情況下，線程將會進入到 BLOCKED（阻塞） 狀態。線程在執行 Runnable 的run()方法之后將會進入到 TERMINATED（終止） 狀態。
3.4. 文件與 I\O 流
3.4.1. Java 中 IO 流分為幾種?
-
按照流的流向分，可以分為輸入流和輸出流；
-
按照操作單元劃分，可以劃分為字節流和字符流；
-
按照流的角色劃分為節點流和處理流。
Java Io 流共涉及 40 多個類，這些類看上去很雜亂，但實際上很有規則，而且彼此之間存在非常緊密的聯系， Java I0 流的 40 多個類都是從如下 4 個抽象類基類中派生出來的。 -
InputStream/Reader: 所有的輸入流的基類，前者是字節輸入流，后者是字符輸入流。
-
OutputStream/Writer: 所有輸出流的基類，前者是字節輸出流，后者是字符輸出流。
按操作方式分類結構圖：
IO-操作方式分類
按操作對象分類結構圖：
IO-操作對象分類
3.4.1.1. 既然有了字節流,為什么還要有字符流?
問題本質想問：不管是文件讀寫還是網絡發送接收，信息的最小存儲單元都是字節，那為什么 I/O 流操作要分為字節流操作和字符流操作呢？
回答：字符流是由 Java 虛擬機將字節轉換得到的，問題就出在這個過程還算是非常耗時，并且，如果我們不知道編碼類型就很容易出現亂碼問題。所以， I/O 流就干脆提供了一個直接操作字符的接口，方便我們平時對字符進行流操作。如果音頻文件、圖片等媒體文件用字節流比較好，如果涉及到字符的話使用字符流比較好。
3.4.1.2. BIO,NIO,AIO 有什么區別?
- BIO (Blocking I/O): 同步阻塞 I/O 模式，數據的讀取寫入必須阻塞在一個線程內等待其完成。在活動連接數不是特別高（小于單機 1000）的情況下，這種模型是比較不錯的，可以讓每一個連接專注于自己的 I/O 并且編程模型簡單，也不用過多考慮系統的過載、限流等問題。線程池本身就是一個天然的漏斗，可以緩沖一些系統處理不了的連接或請求。但是，當面對十萬甚至百萬級連接的時候，傳統的 BIO 模型是無能為力的。因此，我們需要一種更高效的 I/O 處理模型來應對更高的并發量。
- NIO (Non-blocking/New I/O): NIO 是一種同步非阻塞的 I/O 模型，在 Java 1.4 中引入了 NIO 框架，對應 java.nio 包，提供了 Channel , Selector，Buffer 等抽象。NIO 中的 N 可以理解為 Non-blocking，不單純是 New。它支持面向緩沖的，基于通道的 I/O 操作方法。 NIO 提供了與傳統 BIO 模型中的 Socket 和 ServerSocket 相對應的 SocketChannel 和 ServerSocketChannel 兩種不同的套接字通道實現,兩種通道都支持阻塞和非阻塞兩種模式。阻塞模式使用就像傳統中的支持一樣，比較簡單，但是性能和可靠性都不好；非阻塞模式正好與之相反。對于低負載、低并發的應用程序，可以使用同步阻塞 I/O 來提升開發速率和更好的維護性；對于高負載、高并發的（網絡）應用，應使用 NIO 的非阻塞模式來開發
- AIO (Asynchronous I/O): AIO 也就是 NIO 2。在 Java 7 中引入了 NIO 的改進版 NIO 2,它是異步非阻塞的 IO 模型。異步 IO 是基于事件和回調機制實現的，也就是應用操作之后會直接返回，不會堵塞在那里，當后臺處理完成，操作系統會通知相應的線程進行后續的操作。AIO 是異步 IO 的縮寫，雖然 NIO 在網絡操作中，提供了非阻塞的方法，但是 NIO 的 IO 行為還是同步的。對于 NIO 來說，我們的業務線程是在 IO 操作準備好時，得到通知，接著就由這個線程自行進行 IO 操作，IO 操作本身是同步的。查閱網上相關資料，我發現就目前來說 AIO 的應用還不是很廣泛，Netty 之前也嘗試使用過 AIO，不過又放棄了。
總結
以上是生活随笔為你收集整理的Java 基本功之（三）Java 核心技术的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Java 基本功之（二）Java 面向对
- 下一篇： 容器（一）剖析面试最常见问题之 Java