Java 生態與應用：從 JVM 到 Spring 的全景

從一支手機 App 到一座機場的航班系統，背後可能是同一種語言

打開你的 Android 手機，滑開銀行 App 查餘額，那筆查詢請求飛到後端伺服器、穿過好幾層服務、最後落到資料庫——這一路上經手的程式，有很大機率都是用同一種語言寫的：Java。再想想機場的航班顯示系統、券商的下單引擎、電商的訂單服務，這些「不能當機、要扛巨量流量、要跑十年以上」的大型系統，Java 幾乎是預設選項。

如果你已經讀過本專區的 Python 篇，心裡可能會有個疑問：Python 寫起來那麼輕快，為什麼還需要 Java？這正是這篇文章想回答的問題。我們不會把 Python 學過的東西換個語法重講一遍，而是聚焦在 Java 之所以是 Java 的那些特色——它跑在哪裡（JVM）、它為什麼囉嗦（靜態強型別、OOP 優先）、它的記憶體誰在管（自動垃圾回收），以及它撐起了一個多大的生態系。

第一個對比：Java 是「先編譯、再到 JVM 上跑」

在 Python 篇你習慣了「寫完直接 python hello.py 就跑」。Java 多了一道手續：你寫的 .java 原始碼要先被編譯成 .class 位元組碼（bytecode），這份位元組碼再交給 JVM（Java Virtual Machine，Java 虛擬機器） 執行。

// Hello.java
public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello, JVM!");
    }
}

javac Hello.java     # 編譯：產出 Hello.class（位元組碼）
java Hello           # 執行：JVM 載入 Hello.class 並運行
# 輸出：Hello, JVM!

這道手續換來一個著名的口號：「Write Once, Run Anywhere」（一次撰寫，到處執行）。同一份 .class 檔，不管底層是 Windows、Linux 還是 macOS，只要該平台裝了對應的 JVM，就能跑。換句話說，JVM 是一層抽象，把你的程式和真實的作業系統、CPU 隔開了。這跟 C++ 直接編譯成特定平台的機器碼很不一樣——C++ 的執行檔換個平台通常就要重新編譯。

你也會立刻發現 Java 比 Python 囉嗦：要有 public class、要有 main 方法、每行結尾要分號、變數要先宣告型別。這些不是 Java 故意找麻煩，而是它的設計取向：把錯誤盡量擋在編譯期，而不是等到程式跑起來才爆炸。

第二個對比：靜態強型別，讓編譯器先幫你抓錯

Python 是動態型別，變數的型別在執行時才確定。Java 是靜態型別（static typing）：每個變數宣告時就要寫清楚型別，編譯器會在編譯階段檢查型別有沒有用錯。

int age = 20;            // age 一輩子都是 int
String name = "小明";     // name 一輩子都是 String

age = "二十";            // 編譯錯誤！不能把字串塞進 int

相較於 Python 要等到執行那一行、傳錯型別才在 runtime 報錯，Java 在你按下編譯的那一刻就攔住了。對小腳本來說，這像是綁手綁腳；但對一個五十萬行、二十個人協作、要維護十年的大型系統來說，型別就是免費的文件與護欄——你看到一個方法簽名，就知道它收什麼、回什麼，IDE 也能據此提供精準的自動補全與重構。

// 方法簽名本身就說清楚了「收兩個 int，回一個 int」
public static int add(int a, int b) {
    return a + b;
}

這就是為什麼大型系統偏愛 Java：規模越大，型別檢查省下的除錯時間越多。

第三個對比：物件導向是「預設」，不是「選配」

Python 支援物件導向，但你也可以寫一堆散落的函式照樣動。Java 不行——在 Java 裡，所有東西都得待在類別（class）裡面，連 main 都要放在某個 class 中。Java 是 OOP-first（物件導向優先） 的語言。

來看一個完整、可執行的小例子，示範封裝與繼承：

// Animal.java
class Animal {
    private String name;          // private：外界不能直接存取，這叫封裝

    public Animal(String name) {  // 建構子
        this.name = name;
    }

    public String getName() {     // 透過方法存取，才能控制存取規則
        return name;
    }

    public String sound() {
        return "（某種聲音）";
    }
}

class Dog extends Animal {         // Dog 繼承 Animal
    public Dog(String name) {
        super(name);               // 呼叫父類別建構子
    }

    @Override                      // 覆寫父類別的方法
    public String sound() {
        return "汪汪";
    }
}

public class Animal {
    public static void main(String[] args) {
        Animal a = new Dog("小黑");   // 父類別型別，指向子類別物件（多型）
        System.out.println(a.getName() + " 說：" + a.sound());
        // 輸出：小黑 說：汪汪
    }
}

這裡有三個 OOP 核心：封裝（private 把欄位藏起來，只開放方法）、繼承（Dog extends Animal）、多型（用 Animal 型別的變數承接 Dog 物件，a.sound() 會自動呼叫到 Dog 的版本）。@Override 是一個註解（annotation），它讓編譯器幫你確認「你真的有正確覆寫到父類別方法」，是新手避免拼錯方法名的好習慣。

小提醒：上面為了示範把兩個 class 寫在同一段。實務上一個 public class 要獨立成同名的 .java 檔，這裡是為了閱讀方便。

第四個對比：記憶體不用自己管，但「機制」要懂

在 C++ 裡，你 new 出來的物件要自己負責 delete，忘了就記憶體洩漏，刪兩次就崩潰。Java 把這件事交給 GC（Garbage Collection，垃圾回收）：你只管 new 出物件，不需要、也不能手動釋放——當一個物件「再也沒有人引用得到」時，JVM 的垃圾回收器會自動回收它的記憶體。

import java.util.ArrayList;
import java.util.List;

public class Memory {
    public static void main(String[] args) {
        List<String> names = new ArrayList<>();  // new 出一個 List
        names.add("Java");
        names.add("Kotlin");

        names = null;   // 切斷唯一的引用
        // 此刻原本那個 ArrayList 變成「無人可達」，
        // GC 會在某個時間點自動回收它，你不必做任何事
        System.out.println("不用手動釋放記憶體");
        // 輸出：不用手動釋放記憶體
    }
}

GC 是 Java「好寫又安全」的關鍵之一，但它不是魔法：它需要消耗 CPU、偶爾會讓程式短暫暫停。這也是為什麼 GC 的細節會在文末的深入段登場——對要求極致延遲的系統，理解 GC 是調校的基本功。

動手寫一段：用泛型寫一個型別安全的小堆疊

來寫一個完整可跑的程式，順便認識 Java 的泛型（generics）——它讓你寫一個容器，使用時才指定要裝什麼型別，且全程受編譯器型別檢查保護。

// StackDemo.java
import java.util.ArrayList;
import java.util.List;

class MyStack<T> {                 // T 是型別參數，使用時才決定
    private List<T> items = new ArrayList<>();

    public void push(T item) {
        items.add(item);
    }

    public T pop() {               // 回傳型別就是 T，呼叫端不必再轉型
        if (items.isEmpty()) {
            throw new RuntimeException("堆疊是空的");
        }
        return items.remove(items.size() - 1);
    }

    public boolean isEmpty() {
        return items.isEmpty();
    }
}

public class StackDemo {
    public static void main(String[] args) {
        MyStack<String> stack = new MyStack<>();   // 指定裝 String
        stack.push("第一盤");
        stack.push("第二盤");
        stack.push("第三盤");

        while (!stack.isEmpty()) {
            System.out.println("拿走：" + stack.pop());
        }
        // 輸出：
        // 拿走：第三盤
        // 拿走：第二盤
        // 拿走：第一盤
    }
}

注意 MyStack<String>：因為指定了 String，pop() 直接回傳 String，不需要像舊式寫法那樣手動轉型，也不可能不小心 push 進一個整數——編譯器會擋下。堆疊的 push 與 pop 都是均攤 $O(1)$ 的操作。這份型別安全，正是靜態型別語言的甜頭。

Java 撐起的生態系：你會在哪裡遇到它

語言本身只是入口，Java 真正的威力在於它身後的生態系。我們快速走一圈：

Android 行動開發。 全球數十億支 Android 裝置，其 App 長年以 Java 為主力語言。雖然近年 Google 把 Kotlin 推為官方首選，但 Kotlin 也是跑在 JVM（在 Android 上是其變體）上、能與 Java 無縫互通，等於是「站在 Java 生態的肩膀上」。

企業後端（Spring）。 這是 Java 最深的護城河。Spring 與 Spring Boot 框架讓你能快速搭出可上線的後端服務。看一段 Spring Boot 的最小 Web API：

// HelloController.java
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@SpringBootApplication
@RestController
public class HelloController {

    @GetMapping("/hello")          // 對應 HTTP GET /hello
    public String hello() {
        return "來自 Spring Boot 的問候";
    }

    public static void main(String[] args) {
        SpringApplication.run(HelloController.class, args);
        // 啟動後瀏覽 http://localhost:8080/hello
        // 回應：來自 Spring Boot 的問候
    }
}

那些 @SpringBootApplication、@RestController、@GetMapping 都是註解——Spring 在背後讀取這些註解，自動幫你接好 HTTP 路由、依賴注入、設定。銀行、保險、電信、政府系統大量採用這套，因為它穩定、有海量函式庫、有龐大的人才市場。

大型系統與大數據。 許多分散式運算與大數據平台（如 Hadoop、Kafka、Elasticsearch 等）都建在 JVM 上，看中的是 JVM 的成熟、跨平台與長期運行的穩定性。

JVM 語言家族。 這是常被忽略的重點：JVM 不只跑 Java。只要能編譯成 JVM 位元組碼，就能在這個生態裡共存：

• Kotlin：更簡潔、更安全（內建 null 安全），Android 與後端都流行，與 Java 完全互通。
• Scala：融合物件導向與函數式風格，常見於資料工程。
• 還有 Groovy、Clojure 等。

也就是說，學會 JVM 這個平台，你的視野不限於 Java 一種語言。

建置工具：Maven 與 Gradle

當專案大到要依賴幾十個第三方函式庫、要被很多人協作，你不可能手動下載 jar 檔、手動編譯。這時需要建置工具（build tool）幫你管理「依賴下載、編譯、測試、打包」整條流水線。Java 世界兩大主流是 Maven 與 Gradle。

Maven 用 XML（pom.xml）描述專案：

<!-- pom.xml 片段：宣告一個依賴 -->
<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <version>3.2.0</version>
    </dependency>
</dependencies>

Gradle 則用更精簡的腳本（Groovy 或 Kotlin DSL）：

// build.gradle 片段：同樣宣告依賴
dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web:3.2.0'
}

你只要宣告「我要用哪個函式庫的哪個版本」，工具就會自動去中央倉庫下載它、連同它依賴的其他函式庫一起備齊。這跟 Python 的 pip + requirements.txt 角色類似，但 Maven/Gradle 還整合了完整的編譯與打包流程。新手階段先會用 IDE（如 IntelliJ IDEA）內建的 Maven/Gradle 面板按按鈕即可，原理懂了就不慌。

那麼，何時選 Java、何時選 Python 或 C++？

這沒有標準答案，但有清楚的取向。把它當成「工具箱裡挑工具」，而不是「哪個語言最強」：

一句話版本：要快寫快試，找 Python；要穩、要規模、要團隊長期維護，找 Java；要榨乾每一分硬體效能、不能容忍 GC 停頓，找 C++。 Java 的甜蜜點，正是在「Python 太鬆、C++ 太硬」之間那塊「夠快、夠安全、夠好維護」的廣大地帶。

常見錯誤：初學者最容易踩的雷

1. 檔名與 public class 名不一致。 Java 規定：含 public class Foo 的檔案必須叫 Foo.java，大小寫都要一致。叫錯名字直接編譯失敗。

2. 用 == 比較字串內容。 == 比的是「是不是同一個物件」，不是內容。比內容要用 .equals()： java String a = new String("hi"); String b = new String("hi"); System.out.println(a == b); // false（兩個不同物件） System.out.println(a.equals(b)); // true（內容相同）

3. 以為「不用釋放記憶體」就是「不會記憶體問題」。 GC 會回收「無人引用」的物件，但如果你不小心一直把物件塞進一個長壽的集合（如靜態 List）而忘了移除，這些物件「有人引用」就不會被回收，照樣記憶體洩漏。

4. 忘記 Java 從 main 開始，且一切都在 class 裡。 別像寫 Python 腳本那樣把程式碼裸放在檔案頂層——在 Java 那會編譯不過。

5. 把 Java 的囉嗦當成缺點而抗拒它。 那些型別宣告、那些 class，在小程式裡像負擔，在大專案裡是救命的結構。理解「為什麼這樣設計」，比抱怨「為什麼這麼麻煩」更能讓你學得快。

深入探討（研究所視角）：JVM 作為平台，與 GC 的運作原理

到這裡，我們把鏡頭拉遠，看看 Java 真正的核心資產其實不是「Java 這個語言」，而是 JVM 這個平台。

為什麼 JVM 是核心價值。 JVM 在你的程式與底層硬體之間插入了一層抽象。它接受的是標準化的位元組碼，而非特定 CPU 的機器碼。這帶來幾個深遠後果：

• 跨平台：同一份位元組碼，任何裝有對應 JVM 的平台都能執行，作業系統與 CPU 差異被 JVM 吸收。
• 語言中立：JVM 不在乎位元組碼是 Java、Kotlin 還是 Scala 編出來的。位元組碼成為一個共同的中介層，於是整個語言家族能共享同一套函式庫、工具與執行環境。這也是為什麼「學 JVM」比「學 Java」是更大的格局。
• 即時編譯（JIT, Just-In-Time）：JVM 並非單純逐行「直譯」位元組碼。它一開始直譯，同時觀察哪些程式碼是「熱點」（被頻繁執行），再把這些熱點動態編譯成原生機器碼。這讓長時間運行的 Java 服務，效能能逐漸逼近、某些情境甚至媲美原生編譯語言——這正是大型後端服務鍾愛 JVM 的原因之一：跑越久、越熱、越快。
• 執行期最佳化：因為 JIT 是在執行時根據真實的執行狀況做最佳化，它掌握的資訊比 C++ 編譯期更多（例如哪個分支實際上幾乎不走），能做出靜態編譯難以企及的針對性最佳化。

GC 機制概覽。 自動記憶體回收是 JVM 另一塊招牌。其核心問題是：「如何判斷一個物件還需不需要？」主流答案是可達性分析（reachability）——從一組「GC Roots」（如目前執行緒堆疊上的區域變數、靜態欄位等）出發，沿著引用一路走，所有「走得到」的物件視為存活，「走不到」的就是垃圾，可回收。

現代 JVM 的 GC 還建立在一個重要的經驗觀察上——世代假說（generational hypothesis）：絕大多數物件「朝生暮死」，產生後很快就不再被使用。據此，堆積（heap）被分成幾個世代：

• 年輕代（Young Generation）：新物件先放這裡。因為大多很快死亡，這一區回收得頻繁但每次很快（只掃存活的少數，再把它們搬走）。
• 老年代（Old/Tenured Generation）：在年輕代「活過數次回收」的物件會被晉升到此。這一區回收較少發生，但一次掃描成本較高。

把「常死的」與「長壽的」分開管理，讓 GC 能用便宜的方式處理大量短命物件，是現代 GC 高效的關鍵。實務上你會聽到不同的 GC 演算法/收集器（如 G1、ZGC 等），它們在「吞吐量」與「停頓時間」之間做不同取捨——例如延遲敏感的金融交易系統會選擇能把單次停頓壓到極低的收集器。

GC 的代價：Stop-The-World。 GC 不是全程免費的。某些回收階段需要暫停所有應用程式執行緒（稱為 Stop-The-World, STW），以免一邊回收一邊有人改動引用造成不一致。STW 停頓對一般 Web 服務無感，但對要求毫秒級延遲的系統就是大事。這也回應了前面「何時選 C++」的討論：當你連幾毫秒的 GC 停頓都無法接受、或需要對記憶體佈局做精細控制時，沒有 GC 的 C++ 反而是對的選擇。沒有最好的記憶體模型，只有最適合場景的取捨——理解 JVM 把哪些麻煩自動化、又把哪些成本轉嫁到哪裡，正是從「會寫 Java」邁向「懂 Java」的分水嶺。

最後一個收束：相較於 Python 用直譯與動態型別換取開發速度、C++ 用手動記憶體管理換取極致掌控，Java 選擇了 JVM 這條中間路線——用一層虛擬機器，同時買到跨平台、執行期最佳化與自動記憶體安全。代價是啟動較慢、記憶體占用較高、偶有 GC 停頓。看懂這組取捨，你就看懂了 Java 為什麼長成今天這個樣子，也就有能力在下一個專案裡，為對的問題挑對的工具。