115 年 國立中央大學資訊管理學系碩士班甲組《計算機概論》

時間戳記排序 (Timestamp Ordering) 是一種併發控制方法，它為每個交易分配一個唯一的、單調遞增的時間戳記，並根據這些時間戳記來決定交易的執行順序。其核心思想是，如果一個交易試圖讀取一個它之前尚未讀取或寫入的資料項，或者試圖寫入一個它之前尚未寫入的資料項，則該交易可能會被中止。

• (A) Deadlocks caused by circular waits: 時間戳記排序透過其嚴格的順序規則，可以有效防止死鎖的發生。如果交易 T1 需要資源 R1，而交易 T2 需要資源 R2，並且 T1 已經持有 R2，T2 已經持有 R1，形成一個循環等待。在時間戳記排序下，較早的時間戳記的交易會優先獲得資源，如果一個交易需要已經被持有且時間戳記較早的資源，它可能會被中止；反之，如果需要資源的時間戳記較晚，則會等待。這種機制避免了交易之間互相等待資源的情況，進而防止了循環等待造成的死鎖。

• (B) Non-serializable schedules caused by conflicting operations: 時間戳記排序旨在確保交易的

二階段提交 (Two-Phase Commit, 2PC) 是一種分佈式事務的原子提交協定，用於確保在分佈式系統中，多個參與者（節點）上的事務能夠全部成功提交或全部失敗回滾。該協定包含一個協調者 (Coordinator) 和多個參與者 (Participants)。

協調者的主要職責是在第一階段 (準備階段) 要求所有參與者表明它們是否能夠執行事務。在第二階段 (提交階段)，協調者根據所有參與者的回應，做出最終決定：如果所有參與者都準備好了，協調者會通知它們提交；如果任何一個參與者無法準備好，協調者會通知所有參與者回滾。

• (A) To execute local transactions on behalf of participants: 這是參與者的職責，而不是協調者的。參與者負責執行自己本地的數據操作。

核心觀念

本題測驗關聯式資料庫正規化（Database Normalization）理論中的**遞移相依（Transitive Dependency）概念及其與第三正規化（3NF, Third Normal Form）**的關聯。

1. 功能相依（Functional Dependency, FD）：
   設 $R$ 為一關聯綱要（Relation Schema），$X$ 與 $Y$ 為 $R$ 的屬性子集合。若對任意合法的關聯實例，給定 $X$ 的值皆可唯一定位出 $Y$ 的值，記作 $X \rightarrow Y$（稱 $X$ 決定 $Y$，或 $Y$ 相依於 $X$）。
2. 遞移相依（Transitive Dependency）：
   在關聯 $R$ 中，若存在主鍵（或候選鍵）$K$ 以及非鍵屬性集合 $A$ 與 $B$（$B$ 不屬於候選鍵且不相依於 $K$ 的子集），滿足：
   $K \rightarrow A \quad \text{且} \quad A \rightarrow B \quad (\text{其中 } A \not\rightarrow K)$
   則稱屬性 $B$ 遞移相依於主鍵 $K$（透過非鍵屬性 $A$ 傳遞）。
3. 正規化對應：
   • 2NF：消除非鍵屬性對主鍵的「部分相依（Partial Dependency）」。
   • 3NF：已達 2NF，且消除非鍵屬性對主鍵的「遞移相依（Transitive Dependency）」，即不存在非鍵屬性決定另一個非鍵屬性。

---

解題方法

判斷遞移相依的核心在於尋找**「非鍵屬性（Non-key attribute）決定另一個非鍵屬性」**的現象：

• 若主鍵為 $K$，其他皆為非主鍵屬性。由主鍵定義必有 $K \rightarrow A$ 與 $K \rightarrow B$。
• 若在此基礎上，非鍵屬性 $A$ 能決定非鍵屬性 $B$（即 $A \rightarrow B$ 且 $B$ 不是主鍵），則形成 $K \rightarrow A \rightarrow B$ 的相依鏈條。
• 這種「非鍵屬性決定非鍵屬性」的情境，最直接且精確地表徵了遞移相依的存在。

---

選項分析

• (A) A primary key determines all other attributes（錯誤）

第三正規化形式 (3NF) 是資料庫正規化中的一個重要階段。它建立在第二正規化形式 (2NF) 的基礎上，並要求消除傳遞依賴。

• (A) It guarantees lossless decomposition in all cases: 無損分解 (lossless decomposition) 是指將一個關係模式分解成多個較小的模式後，可以透過自然連接 (natural join) 操作無損地恢復原來的模式。2NF 和 3NF 的定義都包含了無損分解的要求。然而，要完全保證無損分解，通常還需要滿足其他條件，例如分解後的模式必須包含原模式的主鍵。雖然 3NF 通常能實現無損分解，但「所有情況下」的保證可能過於絕對，更關鍵的是它解決了什麼問題。

• (B) It eliminates insertion, update, and deletion anomalies caused by transitive dependencies: 這是 3NF 的核心優勢和主要目的。在 2NF 中，雖然消除了部分依賴 (partial dependency)，但傳遞依賴仍然可能存在，導致插入、更新和刪除 Anomalies。

核心觀念

本題考查資料庫安全威脅的分類，重點在於區分：

• 邏輯性安全威脅（logical threat）：透過資料庫的帳號、權限、應用程式或資料操作功能，造成資料遭未授權存取、修改、刪除或竄改。
• 實體性安全威脅（physical threat）：直接破壞伺服器、硬碟、電力或其他硬體設備。
• 網路性安全威脅（network-based threat）：利用網路傳輸或通訊環境進行攔截、竊聽、偽造或封包分析。

資料庫安全通常同時重視三項核心目標：

1. 機密性（Confidentiality）：防止未授權者讀取資料。
2. 完整性（Integrity）：防止資料遭未授權修改或破壞。
3. 可用性（Availability）：確保系統與資料能正常使用。

本題的關鍵是判斷威脅發生在哪一層。若是透過合法帳號或資料庫操作權限進行不當資料修改，屬於邏輯層面的安全問題。

解題方法

逐一觀察各選項的攻擊媒介：

• 若威脅涉及帳號、權限、資料表或資料內容操作，屬於邏輯性威脅。
• 若威脅涉及電力、硬碟或伺服器設備，屬於實體性威脅。
• 若威脅涉及網路封包傳輸，屬於網路性威脅。

SQL 中的 HAVING 子句用於篩選由 GROUP BY 子句產生的分組結果。它與 WHERE 子句的功能不同，WHERE 子句用於篩選單一行記錄，而 HAVING 子句用於篩選整個分組。

• (A) HAVING filters rows before grouping, so it can replace WHERE in all cases: 這是錯誤的。HAVING 子句在 GROUP BY 之後執行，用於篩選分組，而 WHERE 子句在 GROUP BY 之前執行，用於篩選單一行。HAVING 不能在所有情況下取代 WHERE。例如，如果不需要分組，直接用 WHERE 篩選行會更有效率。
• (B) HAVING filters groups after GROUP BY, and it is commonly used with aggregate functions: 這是正確的。HAVING 子句緊跟在 GROUP BY 子句之後，它會對 GROUP BY 生成的分組進行條件篩選。

資料庫中的約束 (Constraints) 用於確保資料的正確性、一致性和完整性。

• (A) Entity integrity (實體完整性): 主要指主鍵 (Primary Key) 的約束。它要求主鍵的值不能為 NULL，且必須是唯一的。這確保了每個記錄（實體）在表中都有一個唯一標識符。
• (B) Referential integrity (參照完整性): 主要指外鍵 (Foreign Key) 的約束。它確保外鍵的值必須存在於其參照的主鍵列中，或者為 NULL。這保證了表之間的關聯性是有效的。

在 ER 模型 (Entity-Relationship Model) 中，多對多 (Many-to-Many, M:N) 的關係是一種常見的結構。當將這種 M:N 關係映射到關係型資料庫時，標準且正確的做法是創建一個「關聯表」(associative table) 或稱為「連結表」(junction table)。

• (A) Place a foreign key of each entity in the other entity's table, and allow duplicates: 這種設計適用於一對多 (1:N) 的關係，其中「多」的一方包含「一」一方的外鍵。對於 M:N 關係，如果這樣做，例如在表 A 中放表 B 的外鍵，在表 B 中放表 A 的外鍵，會導致大量的冗餘和潛在的不一致性，並且無法正確表示 M:N 的多重對應。

索引 (Indexes) 是資料庫中用於加速數據檢索的一種資料結構。它們通過創建指向表中特定列的快速查找機制來提高查詢性能。然而，過度的索引（索引數量過多或索引涵蓋的列過多）可能會對資料庫性能產生負面影響。

• (A) Indexes increase query complexity: 索引本身不會直接增加查詢的「複雜性」 (complexity)，而是增加查詢優化器選擇索引的「複雜性」。查詢優化器需要考慮使用哪些索引，這會增加優化過程的開銷，但這通常是可接受的。索引的主要作用是簡化查詢的「執行」，而不是增加查詢本身的邏輯複雜性。
• (B) Indexes require additional storage and maintenance during data updates: 這是過度索引導致性能下降的最主要原因之一。
  • 額外儲存空間: 每個索引都需要額外的磁碟空間來儲存其結構（例如 B-tree）。

Write-Ahead Logging (WAL) 是一種確保資料庫持久性和恢復機制的技術。其核心原則是：在對數據頁 (data page) 進行任何修改之前，必須先將描述該修改的日誌記錄 (log record) 寫入到穩定的儲存 (stable storage) 中。

• (A) Data pages must be written to disk before the corresponding log records: 這是 WAL 的反面。WAL 的關鍵在於「先寫日誌，後寫數據」，以確保在系統崩潰時，即使數據頁還未寫入磁碟，日誌中也記錄了該修改，以便恢復時重做。
• (B) Log records describing an update must be flushed to stable storage before the updated data page is written to disk: 這是 WAL 的正確描述。

Java 中的異常處理機制允許程式設計師處理運行時可能發生的錯誤。

• (A) A catch block can catch a superclass exception type and handle its subclasses: 這是正確的。在 Java 中，異常類別之間存在繼承關係。如果一個 catch 塊可以捕獲一個父類別的異常類型（例如 Exception），那麼它也能夠捕獲該父類別的所有子類別的異常（例如 IOException, NullPointerException 等）。這使得程式設計師可以更簡潔地編寫異常處理代碼，將相似類型的異常統一處理。
• (B) throw is used to declare that a method may pass an exception to its caller: 這是錯誤的。throw 關鍵字用於在方法內部「拋出」一個異常物件。用來「聲明」一個方法可能會拋出某種異常給呼叫者的是 throws 關鍵字。例如：void myMethod() throws IOException { ... }。

Java 的變數根據其聲明的位置和方式，有不同的作用域 (scope)、生命週期 (lifetime) 和初始化規則。

• (A) Local variables must be explicitly initialized before use: 這是正確的。局部變數 (local variables)，包括方法參數和在方法、代碼塊內部聲明的變數，在聲明時不會被自動初始化。程式設計師必須在第一次使用它們之前，為它們賦予一個初始值。否則，編譯器會報錯，提示變數可能未被初始化。
• (B) Instance variables are automatically initialized with default values: 這是正確的。實例變數 (instance variables)，也稱為成員變數，是在類別內部、方法外部聲明的變數。

Java 中的陣列 (Arrays) 是一種固定大小的序列容器，用於儲存相同類型的元素。

• (A) The length of an array is fixed once the array is created: 這是正確的。一旦在 Java 中創建了一個陣列物件，它的長度（容量）就不能再改變。如果需要一個大小可變的集合，應該使用 ArrayList 等集合類別。
• (B) Array indices in Java start at 1: 這是錯誤的。Java 陣列的索引是基於零的 (zero-based)，即第一個元素的索引是 0，第二個是 1，依此類推。

方法重載 (Method Overloading) 是 Java 中一種允許在同一類別中定義多個同名方法，但它們具有不同參數列表（參數類型、參數個數或參數順序不同）的機制。

• (A) Overloaded methods must have different parameter lists: 這是正確的。這是方法重載的核心要求。參數列表的不同是判斷方法是否重載的唯一標準。參數列表包括參數的類型、數量以及參數的順序。
• (B) Overloaded methods can differ only by return type: 這是錯誤的。僅僅改變返回類型是不夠的。如果兩個方法名稱相同，參數列表也相同，但返回類型不同，Java 編譯器會認為它們是同一個方法，而不是重載。方法重載必須基於參數列表的不同。

這是一個關於 Java 值傳遞 (pass-by-value) 機制的經典問題。

首先，我們分析代碼的執行流程：

1. 在 main 方法中，宣告整數變數 a 並初始化為 10。
2. 創建一個 Counter 物件，並將其引用賦給變數 c。c.value 被初始化為 10。
3. 調用 increment(a, c) 方法。
   • a 是基本類型（int），在傳遞給 increment 方法時，它的值被「複製」過去。方法內的局部變數 x 接收了 a 的值（10）。
   • c 是物件引用。在傳遞給 increment 方法時，c 的值（即對 Counter 物件的引用）被「複製」過去。方法內的局部變數 c 接收了這個引用。
4. 在 increment 方法內部：
   • x = x + 1;：這行代碼修改的是局部變數 x 的值。由於 x 是 a 的一個副本，對 x 的修改不會影響到 main 方法中的 a。所以 a 仍然是 10。
   • c.value = c.value + 1;：這行代碼通過局部變數 c 的引用去訪問 Counter 物件的 value 欄位，並將其加 1。

Java 的多線程機制允許程式同時執行多個任務。創建和管理線程有幾種方式。

• (A) A thread can be created by extending the Thread class: 這是正確的。第一種創建線程的方式是創建一個繼承自 java.lang.Thread 類的子類別，並重寫其 run() 方法。然後，創建該子類別的實例，並調用其 start() 方法來啟動線程。
• (B) A thread can be created by implementing the Runnable interface: 這是正確的。第二種也是更推薦的創建線程的方式是創建一個實現了 java.lang.Runnable 接口的類別，並實現其 run() 方法。然後，創建該類別的實例，並將其作為參數傳遞給 Thread 類的構造函數來創建一個 Thread 物件。

核心觀念

本題探討物件導向程式設計（OOP）中 物件初始化順序（Object Initialization Order） 與 多型／動態繫結（Polymorphism / Dynamic Binding） 的交互作用。核心考核點包含：

1. 子類別建構子的隱式呼叫：當建立子類別物件（new Derived()）時，子類別建構子會先隱式呼叫父類別的無參數建構子 super()。
2. 建構子中呼叫可被覆寫（Overridable）的方法：Java 中非 private、非 static、非 final 的實體方法預設具備多型特性。若父類別建構子中呼叫了已被子類別覆寫的方法，執行期（Runtime）會透過動態繫結呼叫子類別的方法版本。
3. 物件成員變數初始化的時機：父類別建構子執行完畢後，才會輪到子類別實體變數的顯式初始化（Explicit Initialization）。在父類別建構子執行期間，子類別的實體變數尚未賦值，僅具備型別的預設值（對參考型別為 null，對數值型別為 0）。

---

解題方法與執行追蹤

分析 new Derived() 的完整物件初始化順序：

1. 配置記憶體並填入預設值：
   JVM 為 Derived 物件實體配置記憶體，所有欄位被初始化為預設零值。此時 msg 為 null。
2. 觸發子類別建構子：
   進入 Derived 的預設建構子 Derived()。建構子第一行隱式執行 super()，轉而呼叫父類別 Base()。
3. 執行父類別建構子 Base()：
   • 執行 init()。
   • 因為實際執行的物件實體是 Derived，且 Derived 覆寫（Override）了 init()，此處依動態繫結規則呼叫 Derived.init()，而非 Base.init()。
4. 執行 Derived.init()：
   • 執行 System.out.println(msg);。

這段程式碼使用了 Java 的泛型 (Generics) 來創建一個 ArrayList。泛型主要用於在編譯時提供類型安全。

• (A) Only String objects can be added to list: 這是正確的。由於 list 被聲明為 List<String>，這意味著它只能儲存 String 型別的物件。如果嘗試添加其他類型的物件，編譯器將會報錯。
• (B) Elements retrieved from list are of type String without casting: 這是正確的。因為 list 是一個 List<String>，當從中檢索元素時（例如使用 list.get(index)），返回的物件的類型已經是 String，不需要進行強制類型轉換 (casting)。這是泛型提供的主要優勢之一，避免了運行時的 ClassCastException。

這是一個關於 Java 多態性和方法調用的問題。

程式碼流程分析：

1. A x = new B();：這裡聲明了一個父類別 A 的引用變數 x，並將其指向一個子類別 B 的實例。這是一個典型的向上轉型 (upcasting)。
2. x.f();：調用 x 所指向物件的 f() 方法。由於 x 是一個 A 類型的引用，但它實際指向的是一個 B 類型的物件，Java 會根據物件的實際類型來決定調用哪個 f() 方法。這就是動態綁定 (dynamic binding) 或稱為運行時多態 (runtime polymorphism)。
3. B 類別覆蓋 (override) 了 A 類別的 f() 方法。因此，當調用 x.f() 時，實際上會執行 B 類別中的 f() 方法。
4. B 類別的 f() 方法會列印 "B"。
5. 所以，程式的輸出是 "B"。

Java 的記憶體管理涉及幾個關鍵區域：堆 (Heap)、棧 (Stack) 和方法區 (Method Area，在較新版本的 JVM 中稱為元空間 Metaspace)。

• (A) Objects created with new are stored on the heap: 這是正確的。使用 new 關鍵字創建的物件（包括物件的實例數據）都存儲在堆 (Heap) 區域。堆是所有物件共用的記憶體區域，其生命週期由垃圾回收器 (Garbage Collector) 管理。
• (B) Local variables are stored on the heap: 這是錯誤的。局部變數（包括方法參數）存儲在棧 (Stack) 區域。

核心觀念
本題測驗的是 死結 (deadlock) 與活結 (livelock) 的概念與避免／偵測機制。

• 四個 Coffman 條件：互斥 (mutual exclusion)、不可搶占 (non‑preemptive)、保持與等待 (hold‑and‑wait)、循環等待 (circular wait)。只要其中任一條件被破除，就可以保證不會產生死結。
• 活結 (livelock)：系統中所有執行緒仍在不斷變換狀態，但永遠無法取得前進的機會，常因過度的資源搶奪或預先釋放策略而產生。
• 防止死結的常見策略：
  1. 破除 hold‑and‑wait（一次性請求全部資源或允許資源被搶奪）
  2. 嚴格資源序排序（排除循環等待）
  3. 銀行家演算法 (Banker’s Algorithm)：在資源分配前檢查是否仍能維持 安全狀態，屬於死結避免而非活結防止。
• 系統效能考量：避免死結的策略往往會讓資源使用率下降，因為系統必須保留額外的安全餘度或限制資源同時使用，這會降低整體吞吐量 (throughput)。

---

解題方法
針對每個選項，根據上述概念判斷其描述是否符合事實。

1. 先確認選項所涉及的機制是 「防止死結」、「防止活結」，或是 「偵測」 的層面。
2. 若敘述涉及 Banker’s Algorithm，必須檢查其是否直接處理活結（答案為否）。
3. 若涉及 資源排序 或 破除 hold‑and‑wait，檢視是否可能產生活結或同時降低吞吐量。
4. 最後比對 偵測難易度：死結在資源等待圖上呈現環路，容易被偵測；活結則是持續的狀態變換，較難捕捉。

---

選項分析

選項	正確性	解析
(A) Breaking the hold-and-wait condition could prevent deadlock, but may lead to livelock.	✅ 正確	破除 hold‑and‑wait（如「一次性請求全部資源」或「資源可被搶奪」）可以保證不會形成 循環等待 → 無法產生死結。然而，若系統採取「獲取不到全部資源就釋放已持有資源」的策略，執行緒可能會不斷重複 取得 → 失敗 → 釋放 → 再次取得 的循環，形成 活結。因此此敘述正確。

臨界區問題 (Critical-Section Problem) 是指在一個共享資源的環境中，如何確保多個進程或線程在訪問共享資源時，同一時間只有一個能進入其臨界區，以防止數據不一致。硬體提供的原子指令 (atomic instructions) 是解決這個問題的常見方法。

• (A) Hardware atomic instructions eliminate busy waiting: 這是錯誤的。許多硬體原子指令（如 Test-and-Set, Compare-and-Swap）本身是實現「自旋鎖」(spinlocks) 的基礎，而自旋鎖的特點就是「忙等待」(busy waiting)。它們確保了原子操作，但並不直接消除忙等待。
• (B) Disabling interrupts is suitable for multiprocessor systems: 這是錯誤的。在多處理器系統中，禁用中斷 (disabling interrupts) 只能防止本處理器上的進程被調度器中斷，但無法阻止其他處理器上的進程進入臨界區。因此，它不能保證多處理器系統上的互斥。

核心觀念

• 內部碎裂 (Internal Fragmentation)：當記憶體分配單位（如分割槽、頁框）大小固定，而程式實際需求小於此大小時，剩餘未使用的空間稱為內部碎裂。
• 外部碎裂 (External Fragmentation)：在可變大小的分配單位中，已分配的區塊之間留下的零散空間，導致無法滿足新的請求。
• 本題關注的是 「哪種記憶體管理策略可能產生內部碎裂」，因此需要檢視每一策略的分配單位是否為 固定大小。

---

解題方法

1. 先釐清每個選項的記憶體配置機制：
   • Continue Memory Allocation（連續/固定分割槽分配）
   • Segmentation（分段，長度依需求變動）
   • Paging（分頁，頁框大小固定）
   • Segmentation + Paging（先分段再分頁）
   • Segmentation + Continue Memory Allocation（分段後仍以固定分割槽配置）
2. 判斷「是否有固定大小的分配單位」：若有，則 可能產生內部碎裂。
3. 逐項比對，列出會與不會產生內部碎裂的策略。

---

選項分析

選項	記憶體管理機制	是否使用固定大小的分配單位	會否產生內部碎裂	理由
(A) Continue Memory Allocation	連續分配（如固定分割槽或固定分區）	是（每個分割槽大小預先固定）	✅ 會	若程序所需記憶體小於分割槽大小，剩餘空間在分割槽內無法再分配，形成內部碎裂。

RAID (Redundant Array of Independent Disks) 是一種將多個硬碟組合成一個邏輯單元的技術，用於提高數據的性能、可靠性或兩者兼具。

• (A) RAID 0 uses block striping to improve performance but provides no redundancy: 這是正確的。RAID 0 將數據塊分散（striping）到多個磁碟上，以提高讀寫性能。但它沒有任何冗餘機制，任何一個磁碟的故障都會導致整個陣列的數據丟失。
• (B) RAID 1 uses mirroring, which provides high data reliability and has a storage efficiency of 100% because no space is used for parity: 這是錯誤的。RAID 1 使用鏡像 (mirroring)，即將相同的數據寫入兩個或多個磁碟。這提供了高數據可靠性。然而，其儲存效率不是 100%，而是 50%（如果使用兩個磁碟），因為每個數據都有一份副本。它沒有使用奇偶校驗 (parity)，但這並不意味著效率是 100%。

核心觀念

本題考查即時 CPU 排程（Real-Time CPU Scheduling）的基本分類與兩種經典演算法：

• 硬即時系統（Hard Real-Time System）：工作必須在期限（deadline）前完成，錯過期限即代表系統失效。
• 軟即時系統（Soft Real-Time System）：希望工作盡量準時完成，但偶爾錯過期限仍可接受，通常只會造成服務品質下降。
• Rate Monotonic Scheduling, RMS：靜態優先權排程，工作週期越短，優先權越高。
• Earliest Deadline First, EDF：動態優先權排程，期限越早的工作優先權越高。
• 在理想的單處理器、可搶先排程條件下，EDF 的理論 CPU 利用率上限可達 $100\%$。

解題方法

逐一比對每個選項與上述定義：

1. 判斷硬即時與軟即時系統對 deadline 的要求。
2. 判斷 RMS 是依固定的週期決定優先權，還是動態調整。
3. 判斷 EDF 是否會依工作期限動態變更優先權。
4. 使用 CPU 利用率公式確認 EDF 的理論上限。

若工作 $i$ 的執行時間為 $C_i$、週期為 $T_i$，其 CPU 利用率為：

$$U_i=\frac{C_i}{T_i}$$

整體 CPU 利用率為：

$$U=\sum_{i=1}^{n}\frac{C_i}{T_i}$$

單處理器能提供的最大計算能力為 $1$，因此理論上只要：

$$U\leq 1$$

便有機會安排所有工作準時完成。當 $U=1$ 時，代表 CPU 被完全利用，也就是 $100\%$ CPU utilization。

選項分析

(A) Hard real-time systems cannot tolerate missed deadlines.

正確。

硬即時系統要求工作必須在 deadline 前完成，例如飛航控制、汽車煞車控制或工業安全控制。若錯過期限，可能導致系統失效或嚴重後果，因此不能容忍 missed deadlines。

(B) Rate Monotonic Scheduling assigns priority based on period length.

正確。

RMS 依工作週期長短分配固定優先權：

• 週期越短，代表執行頻率越高，優先權越高。
• 週期越長，優先權越低。

因此若工作 $J_1$ 的週期為 $10$，工作 $J_2$ 的週期為 $20$，則：

拜占庭將軍問題 (Byzantine Generals Problem) 是分散式系統理論中的一個經典問題，它描述了如何讓一群分散式的將軍（節點）在存在叛徒（故障節點）的情況下，對是否攻擊達成一致的決策。它引出了拜占庭容錯 (Byzantine Fault Tolerance, BFT) 的概念，即系統能夠在部分節點出錯（甚至惡意行為）的情況下，仍然保持正確運行。

• (A) The Byzantine Generals Problem has important implications for distributed file systems and distributed lock services: 這是正確的。分散式檔案系統需要確保數據的一致性，即使部分節點失效或惡意。分散式鎖服務也需要保證鎖的正確獲取和釋放，即使有節點故障。BFT 對於這些系統的可靠性至關重要。
• (B) Components of operating system kernel are typically assumed that they will not exhibit Byzantine faults: 這是正確的。在設計操作系統內核時，通常假設內核組件是可靠的，不會出現惡意的拜占庭故障，而是最多出現隨機故障。如果內核需要處理拜占庭故障，其設計將會變得極其複雜。

進程 (processes) 和線程 (threads) 是並發執行和資源共享的基本單元。它們之間的同步和通信是並發編程中的重要課題。

• (A) Different processes could directly share each other's local (stack) variables by default: 這是錯誤的。進程之間是獨立的記憶體空間，它們的局部變數（位於棧上）是相互隔離的，不能直接共享。進程間通信 (IPC) 需要藉助特殊的機制，如共享記憶體、管道、訊息佇列等。
• (B) Threads within the same process could communicate through shared memory: 這是正確的。同一進程中的線程共享該進程的記憶體空間，包括代碼段、數據段和堆。因此，它們可以通過共享變數（位於數據段或堆上）來直接通信。

這是一個關於磁碟 free space 管理的問題，特別是使用位元圖 (bitmap) 的方法。

首先，我們計算一些基本資訊：
磁碟總容量 = 2 TB = 2 * 1024 GB = 2 * 1024 * 1024 MB = 2 * 1024 * 1024 * 1024 KB
Block size = 4 KB

一個 block 代表 4 KB 的儲存空間。
位元圖 (bitmap) 中的每一位 (bit) 對應一個 block。
bitmap 中，0 代表 free，1 代表 occupied (或反之，取決於實作)。這裡假設 1 代表 free，0 代表 occupied，或者反之。重點是每一位代表一個 block 的狀態。

總共的 block 數量 = 磁碟總容量 / Block size
= (2 * 1024 * 1024 * 1024 KB) / 4 KB
= 2 * 1024 * 1024 * 256
= 524,288,000 blocks

位元圖需要為每個 block 儲存一個位元。
所以，位元圖所需的位元數 = 總 block 數量 = 524,288,000 bits
位元圖所需的位元組數 = 位元數 / 8 bits/byte
= 524,288,000 / 8
= 65,536,000 bytes
= 65,536,000 / 1024 KB
= 64,000 KB
= 64 MB

現在我們來分析每個選項：

• (A) bitmap 不需帶入記憶體中也能維持良好系統效能,因為位元運算簡單有效率。
  這是錯誤的。雖然位元運算本身簡單有效率，但為了快速存取和管理磁碟空間，bitmap 必須載入到主記憶體 (RAM) 中。磁碟 I/O 操作非常慢，如果每次查詢 free space 都需要讀取磁碟上的 bitmap，系統效能將會非常低。因此，bitmap 通常會被快取在記憶體中。

• (B) 需要的 bitmap 大小約為64 MB。
  根據我們的計算，64,000 KB = 64 MB。所以這個敘述是正確的。

• (C) Counting 方法會記錄“第一個 free block位址”以及“連續free blocks的數量”。

systemctl 是 Linux 系統中用於管理 systemd 服務管理器（service manager）的命令。它用於控制系統服務的啟動、停止、狀態查詢、開機啟動設置等。

讓我們逐一分析選項：

• (A) systemctl remove nginx (移除nginx服務): 這是錯誤的。systemctl 命令本身不直接用於「移除」服務的安裝文件。移除服務通常需要使用包管理器（如 apt remove nginx 或 yum remove nginx）。systemctl disable nginx 用於取消開機啟動，systemctl stop nginx 用於停止服務，但 remove 不是 systemctl 的標準操作。
• (B) systemctl start nginx (啟動 nginx 服務): 這是正確的。systemctl start <service_name> 用於立即啟動指定的服務。

管線 (pipe, |) 是 Unix-like 操作系統中一個強大的功能，它允許將一個命令的標準輸出 (stdout) 作為另一個命令的標準輸入 (stdin)。這使得可以將多個簡單的命令組合起來，完成複雜的任務。

讓我們逐一分析每個選項：

• (A) ls -1 | mysavelist.txt (將ls -1 的結果存入 mysavelist.txt 檔案中):
  這是錯誤的。管線 (|) 的作用是將一個命令的輸出傳遞給下一個命令的輸入。mysavelist.txt 是一個檔案名，而不是一個命令。如果想將 ls -1 的結果存入檔案，應該使用重定向符號 >，例如 ls -1 > mysavelist.txt。將 ls -1 的輸出傳遞給一個檔案名作為輸入，在語法上是錯誤的，或者在某些 shell 中可能會被解釋為嘗試執行該檔案名作為命令，導致錯誤。

• (B) find. -name "*.tmp" | rm (搜尋附檔名為tmp的檔案,並將其刪除):
  這是錯誤的。find 命令會列出找到的檔案名，但 rm 命令期望的輸入格式通常是直接的檔案名列表，而不是通過管線傳遞過來的檔案名列表。直接將 find 的輸出傳給 rm，rm 會嘗試將這些檔案名作為它自己的參數來處理，而不是將它們作為標準輸入。
  正確的做法通常是使用 find 命令的 -exec 選項，或者結合 xargs 命令：

  • find . -name "*.tmp" -exec rm {} \; (逐個執行 rm)
  • find . -name "*.tmp" -print0 | xargs -0 rm (更安全高效，處理包含空格或特殊字符的檔名)
    單純使用 | rm 是不正確的。