113 年 國立中央大學企業管理學系碩士班戊組《計算機概論》

QUIC 協定是由 Google 在 2012 年提出的，最初稱為 "Quick UDP Internet Connections"，旨在改善網際網路上的傳輸效能，特別是在高延遲或不穩定網路環境下。其發展背景主要可以歸納為以下幾點：

1. TCP 的限制： 傳統的網際網路傳輸主要依賴 TCP (Transmission Control Protocol)。TCP 雖然提供了可靠的、有序的資料傳輸，但其設計在現代網路環境中顯露出一些缺點：

   • Head-of-Line Blocking (HOLB)： 在 TCP 中，如果封包在傳輸過程中丟失，即使後續的封包都已成功送達，整個連線也必須等待丟失的封包重傳，這會導致整個串流的延遲。這種情況在多個應用程式共用一個 TCP 連線時尤其嚴重，一個應用程式的封包丟失會影響到其他應用程式。
   • 連線建立延遲： TCP 的三次握手（three-way handshake）需要來回傳輸四個封包（SYN, SYN-ACK, ACK），加上 TLS/SSL 的握手（通常需要額外的 1-2 次往返），這會顯著增加網頁或應用程式的初始載入時間。
   • 缺乏彈性與可擴展性： TCP 的核心協議由作業系統內核管理，更新和修改協議非常困難且緩慢。這使得引入新的傳輸機制或優化變得不切實際。

2. HTTP/2 的推動： HTTP/2 協定引入了多工（multiplexing）和伺服器推播（server push）等特性，試圖解決 HTTP/1.1 的性能瓶頸。然而，HTTP/2 仍然基於 TCP，因此無法完全擺脫 TCP 的 HOLB 問題。當 TCP 封包丟失時，所有 HTTP/2 的多工串流都會受到影響。

3. UDP 的潛力： UDP (User Datagram Protocol) 是一種無連接、不可靠的傳輸協議，傳輸速度快，但缺乏流量控制、擁塞控制和可靠性保證。QUIC 選擇基於 UDP，是為了繞過 TCP 的限制，並在應用層實現更靈活、更高效的傳輸控制。

QUIC 的主要特色：

QUIC 結合了 UDP 的靈活性和 TCP 的可靠性，並引入了許多現代化的設計，其主要特色包括：

VPN (Virtual Private Network) 是一種技術，它允許使用者在公共網路（如網際網路）上建立一個加密的、安全的通道，以遠端存取組織的內部網路資源，或者在不同地點之間建立安全的點對點連線。其主要功能包括：

• 遠端存取： 允許遠端員工或使用者安全地存取公司內部伺服器、檔案共享、應用程式等資源，如同他們身處於公司內部網路一樣。
• 站點對站點連線： 在地理上分散的分公司或辦公室之間建立安全的網路連接，使它們能夠像在同一內部網路一樣進行通訊和資源共享。
• 保護資料傳輸： 通過加密，VPN 可以保護在公共網路上傳輸的敏感資料免受竊聽和攔截。
• 繞過地理限制： 有時 VPN 也被用於存取地理區域限制的內容或服務。

接下來，我們比較 IPSec VPN、SSL VPN 和 MPLS VPN 這三種常見的 VPN 技術：

1. IPSec VPN (Internet Protocol Security VPN)

• 運作層級： 主要運作在網路層 (Layer 3)。
• 核心技術： 使用 IPSec 協定套件來提供安全服務，包括：
  • 認證標頭 (AH - Authentication Header)： 提供資料來源的認證和資料的完整性保護。
  • 封裝安全載荷 (ESP - Encapsulating Security Payload)： 提供資料的機密性（加密）、完整性、來源認證和防重播保護。
  • Internet 金鑰交換 (IKE - Internet Key Exchange)： 用於協商安全關聯 (Security Association, SA)，包括加密演算法、金鑰等。
• 主要模式：
  • 傳輸模式 (Transport Mode)： 只加密 IP 資料包的載荷（payload），IP 標頭保持不變。通常用於點對點的終端設備之間的安全通訊。
  • 通道模式 (Tunnel Mode)： 將整個原始 IP 資料包（包括 IP 標頭）進行加密和封裝，並加上新的 IP 標頭。這種模式常用於建立 VPN 通道，例如遠端存取 VPN 或站點對站點 VPN。
• 優點：
  • 提供非常強大的安全性，因為它在網路層進行封裝和加密，可以保護所有基於 IP 的流量。
  • 標準化程度高，互通性較好。
  • 適用於保護各種網路流量。
• 缺點：
  • 配置相對複雜，需要對網路層和 IPSec 協定有較深入的了解。
  • 可能會增加網路延遲，尤其是在大量加密和解密操作時。
  • 在 NAT (Network Address Translation) 環境下可能遇到問題，需要 NAT-Traversal 技術。

2. SSL VPN (Secure Sockets Layer VPN)

• 運作層級： 主要運作在應用層 (Layer 7)，基於 SSL/TLS 協定。
• 核心技術： 利用 SSL/TLS 協定來建立安全通道，對應用層流量進行加密和認證。
• 主要模式：
  • 基於閘道器 (Gateway-based)： 遠端使用者透過瀏覽器或專門的 SSL VPN 用戶端軟體，連接到 SSL VPN 閘道器，然後存取內部資源。
  • 基於應用程式 (Application-based)： 僅對特定應用程式的流量進行加密，例如透過瀏覽器存取 Web 應用程式。
• 優點：
  • 易於部署和管理，通常只需要網頁瀏覽器即可存取，無需安裝複雜的用戶端軟體（對於基於瀏覽器的模式）。
  • 對 NAT 環境友好，因為它通常使用標準的 HTTPS 埠號 (443)。
  • 更靈活，可以精確控制使用者對特定應用程式或資源的存取權限。
• 缺點：
  • 安全性可能不如 IPSec VPN，因為它只加密應用層流量，對於非 SSL/TLS 協定的流量可能無法提供保護（除非使用專門的用戶端軟體）。
  • 效能可能受限於 SSL/TLS 加密和解密的處理速度。
  • 主要用於遠端存取，較少用於站點對站點的連接。

3. MPLS VPN (Multiprotocol Label Switching VPN)

• 運作層級： 主要運作在資料鏈路層 (Layer 2) 或網路層 (Layer 3)，但其核心是標籤交換。
• 核心技術： 結合 MPLS 技術和 VPN 技術。MPLS 是一種在電信網路上實現高效封包轉發的技術，它為封包加上標籤（label），路由器根據標籤而不是 IP 位址來轉發封包。

核心觀念

本題考查分頁系統中的三個重要概念：

1. TLB Reach：TLB 可同時快取的頁面數乘以每頁大小。
2. 實體位址空間：由實體頁框數與頁內位移共同決定。
3. 有效存取時間（EAT）：依 TLB 命中與未命中兩種情況加權平均。

頁面大小為 $512\text{ B}$，因此頁內位移所需位元數為：

$$\log_2 512=9\text{ bits}$$

---

甲、TLB 觸及範圍

TLB Reach 的公式為：

$$\text{TLB Reach} = \text{TLB entries}\times \text{page size}$$

代入題目資料：

$$1024\times512 = 524288\text{ B}$$

換算為：

$$524288\text{ B}=512\text{ KB}$$

因此：

$$\boxed{\text{TLB Reach}=512\text{ KB}}$$

補充：這是依 TLB 容量計算出的標準 TLB Reach。題目中的分頁表只有 $64$ 個項目，因此該分頁表實際可描述的虛擬頁面總容量為：

$$64\times512=32768\text{ B}=32\text{ KB}$$

但 TLB Reach 的定義仍依 TLB 項目數與頁面大小計算。

---

乙、實體位址空間大小

每個分頁表項目存放的基底位置共 $11$ bits，其中包含 $1$ bit 的 valid/invalid bit。

因此，真正用來表示實體頁框編號的位元數為：

$$11-1=10\text{ bits}$$

可表示的實體頁框數為：

$$2^{10}=1024\text{ 個}$$

每個頁框大小與頁面大小相同，皆為 $512\text{ B}=2^9\text{ B}$。

因此實體位址總大小為：

$$2^{10}\times2^9 = 2^{19}\text{ B}$$

換算為：

$$2^{19}\text{ B}=524288\text{ B}=512\text{ KB}$$

所以實體位址包含：

• 實體頁框編號：$10$ bits
• 頁內位移：$9$ bits

總實體位址長度為：

核心觀念

本題的核心在於作業系統（OS）中**行程建立（Process Creation）與執行緒建立（Thread Creation）**的機制及其生命週期狀態追蹤：

1. fork() 系統呼叫：
   • 建立當前行程的副本（子行程）。
   • 對父行程（Parent Process）回傳子行程的 PID（值大於 $0$）。
   • 對子行程（Child Process）回傳 $0$。
   • 若呼叫成功，每次呼叫都會使執行到該行的現有行程數量翻倍。
2. thread_create(...)（如 POSIX pthread_create）：
   • 在當前所屬行程內部建立一條新的執行緒（Thread）。
   • 一個行程在初始建立時，本身就包含一條「主執行緒（Main Thread）」。
   • 若呼叫一次 thread_create(...)，該行程內便會新增一條獨立的執行緒，使該行程內的執行緒總數變為 $1 + 1 = 2$ 條。
3. fork() 與 Multi-threading 的語意（POSIX 規範）：
   • 當一個擁有多個執行緒的行程呼叫 fork() 時，作業系統僅會複製呼叫 fork() 的該條執行緒到新行程中成為其唯一的主執行緒，而不會複製其他背景執行緒。

---

解題方法與詳細步驟

我們將程式碼依執行順序分為四個階段進行推導：

pid_t pid;
pid = fork();                  /* 階段一：第 1 次 fork */
if (pid == 0) {                /* 階段二：條件判斷 */
    fork();                    /* 階段二內部：第 2 次 fork */
}
thread_create(...);            /* 階段三：建立執行緒 */
fork();                        /* 階段四：第 3 次 fork */

階段一：第 1 次 fork()

• 初始狀態：系統中只有 $1$ 個原始行程 $P_0$。
• $P_0$ 呼叫 fork()，產生子行程 $P_1$。
• 此時行程數：$2$ 個（$P_0$ 與 $P_1$）。
• 回傳值區分：
  • 在父行程 $P_0$ 中，pid > 0。
  • 在子行程 $P_1$ 中，pid == 0。

階段二：條件式 if (pid == 0)

• 只有子行程 $P_1$ 滿足條件進入區塊內執行 fork()。
• $P_1$ 呼叫 fork()，分裂出新子行程 $P_2$。
• 父行程 $P_0$ 條件不符，直接跳過此區塊。
• 此時行程數：共 $3$ 個行程（$P_0, P_1, P_2$）。

階段三：thread_create(...)

• 當時存在的 $3$ 個行程（$P_0, P_1, P_2$）皆會執行此行指令。
• 每個行程原本皆有 $1$ 條主執行緒，各自呼叫 thread_create(...) 後：
  • 每個行程新增 $1$ 條子執行緒。

資料庫正規化（Database Normalization）是資料庫設計中的一個重要過程，旨在減少資料冗餘（redundancy）並改善資料的完整性（integrity）。1NF、2NF 和 3NF 是正規化過程中的前三個範式（Normal Forms），它們的發展都基於一個核心觀念。

核心觀念：函數依賴 (Functional Dependency, FD)

1NF, 2NF, 3NF 的發展都圍繞著如何處理和消除資料中的異常（anomalies），而這些異常的根源在於不恰當的函數依賴關係。

• 函數依賴 (FD)： 若屬性集合 X 的值唯一確定了屬性集合 Y 的值，則稱 Y 函數依賴於 X，記作 $X \rightarrow Y$。
  • 例如，在一個學生表中，學號 (StudentID) 唯一確定了學生的姓名 (StudentName)，所以 StudentID $\rightarrow$ StudentName。

各範式的定義與核心觀念的體現：

• 第一範式 (1NF)： 要求關係模式中的所有屬性值都是不可再分的原子值。

  • 核心觀念體現： 雖然 1NF 主要關注屬性值的原子性，但它也隱含了對單一值的依賴。如果一個屬性可以被分解，那麼可能存在對其部分或全部的依賴。1NF 是所有更高範式的前提。

• 第二範式 (2NF)： 要求關係模式必須是 1NF，並且所有非主屬性（non-prime attributes）必須完全函數依賴於主鍵（primary key）。

  • 核心觀念體現： 2NF 關注的是主鍵的完全依賴。它解決了「部分函數依賴」問題。

這題考驗對 C 語言指標 (pointer) 操作以及變數在記憶體中的行為的理解。

核心觀念：

• 指標 (Pointer)： 一個變數，其值是另一個變數的記憶體地址。
• & 運算符： 取址運算符，用於獲取變數的記憶體地址。
• * 運算符 (解引用)： 透過指標訪問其指向的記憶體位置的值。
• 變數在記憶體中的分配： 變數在記憶體中佔據一定的空間，每個字節都有一個地址。

---

程式碼分析與記憶體狀態追蹤：

首先，我們需要了解變數在記憶體中的位置和初始值。

• 變數 a 的值是 11，記憶體地址是 0X0012FF74。
• 變數 b 的值是 21，記憶體地址是 0X0012FF78。
• int 型別通常佔 4 個字節。所以，a 佔據 0X0012FF74 到 0X0012FF77，b 佔據 0X0012FF78 到 0X0012FF7B。

位址	值 (Hex)	值 (Dec)	變數
0X0012FF74	0B	11	a
0X0012FF75	00	0	a
0X0012FF76	00	0	a
0X0012FF77	00	0	a
0X0012FF78	15	21	b
0X0012FF79	00	0	b
0X0012FF7A	00	0	b

本題的核心觀念為關聯式資料庫的正規化理論（Normalization Theory），重點考驗考生對正規形（1NF、2NF、3NF、BCNF）的判斷條件、遞移相依（Transitive Dependency）的消除與正規化分解，以及正規化在極端狀況下對於消除資料重複（Data Redundancy）與節省儲存空間的量化分析。

---

(a) 甲

解題過程與觀念說明：

1. 候選鍵（Candidate Key）與主鍵（Primary Key）分析：
   題目給定 $A$ 為 Primary Key 且為唯一的 Candidate Key。
   因此，主屬性（Prime Attribute）為 $A$；非主屬性（Non-prime Attributes）為 $B, C, D$。

2. 第一正規形（1NF）檢查：
   Table $X$ 的所有屬性皆為單一值且不可再分（Atomic Domain），因此符合 1NF。

3. 第二正規形（2NF）檢查：
   2NF 要求「消除部分相依（Partial Functional Dependency）」，即所有非主屬性必須完全函數相依於候選鍵。
   因為本題的 Candidate Key 僅由單一屬性 $A$ 組成（非複合鍵），故不可能存在對候選鍵「部分子集」的相依。所有非主屬性 $B, C, D$ 均完全相依於主鍵 $A$（即 $A \to B, C, D$），故符合 2NF。

4. 第三正規形（3NF）檢查：
   3NF 要求「消除遞移相依（Transitive Functional Dependency）」。對於任何非平凡的函數相依 $Y \to Z$，必須滿足下列條件之一：

   • $Y$ 為 Superkey（超鍵）。
   • $Z$ 為 Prime Attribute（主屬性）。
     觀察題目給定的函數相依 $B \to D$：
   • $B$ 並非 Superkey（因為 $B$ 無法決定 $A$ 與 $C$）。
   • $D$ 是非主屬性（Non-prime Attribute）。
     由於存在 $A \to B$ 且 $B \to D$，導致非主屬性 $D$ 遞移相依於主鍵 $A$。因此，Table $X$ 不符合 3NF。

綜合上述，Table $X$ 僅滿足第 1 正規形與第 2 正規形。

【答案】Table $X$ 滿足 1st NF 與 2nd NF（但不滿足 3rd NF）。原因在於 Candidate Key 為單一屬性 $A$，故無部分相依（滿足 2NF）；但存在函數相依 $B \to D$，其中 $B$ 非超鍵且 $D$ 非主屬性，造成遞移相依 $A \to B \to D$，因而違反 3NF。

---

(b) 乙

解題過程與觀念說明：

1. 是否需要進一步正規化？
   需要。因為 Table $X$ 存在遞移相依 $B \to D$，在未正規化的狀況下會引發資料異常（Anomalies）：

   • 新增異常（Insertion Anomaly）： 若要新增一組 $B \to D$ 的對應關係，但在尚無對應 $A$ 值時無法存入。
   • 刪除異常（Deletion Anomaly）： 刪除某筆 $A$ 資料時，可能不小心一併刪除唯一的 $B \to D$ 資訊。
   • 更新異常（Update Anomaly）： 若某個 $B$ 對應的 $D$ 需要修改，必須同步修改多筆重複資料，否則會造成資料不一致。

2. 如何進行正規化分解（Decomposition）：
   為了消除 $B \to D$ 帶來的遞移相依，依據正規化定理，將 Table $X(A, B, C, D)$ 分解為兩個關聯表：

   • $X_1(B, D)$：主鍵為 $B$，包含函數相依 $B \to D$。

本題考查資料庫系統（Database Systems）中「併發控制（Concurrency Control）」與「封鎖機制（Locking Mechanism）」的核心觀念。主要涵蓋兩個層面：一是鎖的類型與相容性（Lock Types & Compatibility），即共享鎖（Shared Lock）與排他鎖（Exclusive Lock）在讀寫權限與多交易（Transaction）間互斥排他性的差異；二是封鎖粒度（Lock Granularity），即鎖定資料範圍的大小（如 Tuple vs. Table）對系統併發度（Concurrency）、管理開銷（Overhead）與死鎖風險（Deadlock Risk）之間的權衡（Trade-off）。

---

(a) 甲、共享鎖 (Shared Lock) 與排他鎖 (Exclusive Lock) 之差異說明

在資料庫交易處理中，共享鎖（簡稱 $S$ 鎖，又稱 Read Lock）與排他鎖（簡稱 $X$ 鎖，又稱 Write Lock）施加於資料項目（Data Item）時，其主要差異在於操作存取權限與多交易間的相容性（Compatibility）：

1. 操作存取權限 (Access Permissions)：

   • 共享鎖 ($S$ 鎖)：當交易對某資料項目取得 $S$ 鎖後，該交易僅獲得**讀取（Read）**該項目的權限，不可修改或寫入（Write）。
   • 排他鎖 ($X$ 鎖)：當交易對某資料項目取得 $X$ 鎖後，該交易同時獲得**讀取（Read）與寫入（Write）**該項目的完整權限。

2. 多交易相容性與併發性 (Compatibility & Concurrency)：

   • 共享鎖 ($S$ 鎖)：具有相容性。多個交易可以同時對同一資料項目持有 $S$ 鎖（即 $S-S$ 相容）。這允許系統實現併發讀取（Concurrent Read），不會造成資料不一致問題。
   • 排他鎖 ($X$ 鎖)：具有獨佔排他性。一旦某交易對資料項目持有 $X$ 鎖，任何其他交易均無法獲取該項目的 $S$ 鎖或 $X$ 鎖（即 $S-X$、 $X-S$、 $X-X$ 皆不相容）。此機制是為了保護正在進行寫入的資料，避免產生髒讀（Dirty Read）、不可重複讀（Non-repeatable Read）或丟失更新（Lost Update）等衝突。

3. 鎖相容性矩陣 (Lock Compatibility Matrix)：

已持有鎖 \ 請求鎖	$S$ 鎖 (Shared Lock)	$X$ 鎖 (Exclusive Lock)
$S$ 鎖 (Shared Lock)	允許 (Compatible)	拒絕 (Incompatible)
$X$ 鎖 (Exclusive Lock)	拒絕 (Incompatible)	拒絕 (Incompatible)

本題的核心考點在於不使用第三個變數（Temporary Variable）來交換兩個變數數值的程式設計技巧，主要考驗對**位元運算子（Bitwise XOR）與算術運算（加減法）**特性的理解，以及 Java 基本語法與變數運作機制的熟練度。

---

解題過程與邏輯說明

在不使用額外記憶體空間（第三個變數）的前提下，常見的交換演算法主要有兩種：

方法一：位元互斥或運算（Bitwise XOR Swap，推薦標準解法）

XOR 運算（在 Java 中為 ^ 運算子）具備以下三個重要的數學特性：

1. 自我消去性：$x \oplus x = 0$
2. 單位元特性：$x \oplus 0 = x$
3. 交換律與結合律：$x \oplus y = y \oplus x$ 且 $(x \oplus y) \oplus z = x \oplus (y \oplus z)$

假設有兩個整數變數 $a$ 與 $b$，交換步驟如下：

1. 第一步： $a = a \oplus b$
   • 為什麼：將 $a$ 與 $b$ 的混合資訊（兩者的 XOR 結果）暫存於變數 $a$ 中。此時 $a$ 包含了還原 $a$ 與 $b$ 所需的全域資訊。
2. 第二步： $b = a \oplus b$
   • 為什麼：將新的 $a$（即 $a \oplus b$）與原來的 $b$ 進行 XOR。利用結合律與自我消去性：
     $b = (a \oplus b) \oplus b = a \oplus (b \oplus b) = a \oplus 0 = a$
     此時變數 $b$ 已成功更新為原來的 $a$ 值。
3. 第三步： $a = a \oplus b$
   • 為什麼：將第一步得到的混合資訊 $a$（即 $a \oplus b$）與第二步更新後的 $b$（即原來的 $a$）進行 XOR：
     $a = (a \oplus b) \oplus a = (a \oplus a) \oplus b = 0 \oplus b = b$
     此時變數 $a$ 已成功更新為原來的 $b$ 值，完成交換。

本題考查的核心觀念包含：質數判別（Prime Testing）演算法的設計與效能最佳化、試除法（Trial Division）上限的數學證明、Wheel Factorization（車輪因數分解法，如 $6k \pm 1$ 優化），以及 Java Console 輸入/輸出與控制結構。此題之評分關鍵在於能否證明演算法具備最佳的時間複雜度 $O(\sqrt{n})$ 與常數項最佳化，而非僅寫出基礎的試除迴圈。

---

1. 演算法設計與效能最佳化說明

本題要求編寫一 Java 程式，接收使用者輸入的整數 $n$，並輸出 $n$ 是否為質數（必須同時印出輸入數字與結果），且明確禁止呼叫 Java 內建庫（如 BigInteger.isProbablePrime）。以下針對演算法之正確性與最高效率設計進行分步證明：

(1) 搜尋上限最佳化：縮減至 $\sqrt{n}$

【為什麼只需檢查至 $\sqrt{n}$？】
假設整數 $n$ 為合數（Composite Number），則必可分解為兩個大於 $1$ 的整數相乘，即 $n = a \times b$（不妨設 $a \le b$）。
若 $a > \sqrt{n}$，則 $b \ge a > \sqrt{n}$，可推得：
$a \times b > \sqrt{n} \times \sqrt{n} = n$
此結果與 $a \times b = n$ 產生矛盾！
因此，$n$ 若為合數，其最小的非 $1$ 因數 $a$ 必定滿足 $a \le \sqrt{n}$。我們只需檢查至 $\lfloor\sqrt{n}\rfloor$ 即可；若在此範圍內找不到任何能整除 $n$ 的數，則 $n$ 必為質數。

• 時間複雜度由傳統試除法的 $O(n)$ 降至 $O(\sqrt{n})$。

(2) 候選因數最佳化：$6k \pm 1$ 篩選法（Wheel Factorization）

【為什麼只需檢查 $6k \pm 1$ 形式的數字？】
所有大於 $3$ 的正整數均可表示為以下六種形式之一（其中 $k \ge 1$）：
$6k, \quad 6k+1, \quad 6k+2, \quad 6k+3, \quad 6k+4, \quad 6k+5$
觀察各項的因子特性：

• $6k, 6k+2, 6k+4$ 均可被 $2$ 整除（偶數）。
• $6k+3$ 可被 $3$ 整除。
• $6k+5$ 等價於 $6(k+1)-1$。

因此，除了 $2$ 與 $3$ 本身之外，所有質數必定落在 $6k+1$ 或 $6k-1$ 兩種形式中。
在演算法設計中：

1. 先排除 $n \le 1$（非質數）、處理 $n = 2, 3$（質數）。
2. 排除所有 $2$ 與 $3$ 的倍數（n % 2 == 0 || n % 3 == 0）。
3. 測試迴圈變數 $i$ 自 $5$（即 $6(1)-1$）開始，每次增加 $6$，於迴圈內僅需檢測 $i$（即 $6k-1$）與 $i+2$（即 $6k+1$）是否能整除 $n$。

【效率比較】

• 基礎試除法：需檢查約 $n$ 個數。
• 奇數試除法（排除偶數）：需檢查約 $\frac{\sqrt{n}}{2}$ 個數。
• $6k \pm 1$ 優化試除法：僅需檢查約 $\frac{\sqrt{n}}{3}$ 個數。比僅排除偶數的方法再減少約 $33.3\%$ 的除法運算，為單次確定性試除法（Deterministic Trial Division）中效率最高的做法。

---

2. 完整 Java 程式碼