Disable UDP to solve frequent RDP disconnection

解決 RDP 遠端桌面經常斷線問題：「關閉 UDP 傳輸」

---

在使用 Windows 內建的遠端桌面（RDP, Remote Desktop Protocol）連線時，你是否也常遇到連線突然卡死、畫面凍結，或是頻繁跳出「連線已中斷，正在嘗試重新連線」的提示？

這類問題通常與網路環境對 UDP 協定 的支援程度有關。雖然 UDP 具備低延遲的特性，但在某些防火牆、VPN 或不穩定的 Wi-Fi 環境下，UDP 封包容易遺失，進而導致 RDP 連線不斷斷線。

解決方案：將 RDP 連線改為僅使用傳統且穩定的 TCP 協定！

設定步驟（透過群組原則編輯器）

請在發起連線的用戶端電腦（Client）上執行以下設定：

1. 按鍵盤上的 Win + R 開啟「執行」視窗，輸入 gpedit.msc 並按下Enter，開啟「群組原則編輯器」。
2. 在左側樹狀選單中，依序展開至以下路徑：
   電腦設定 (Computer Configuration) > 系統管理範本 (Administrative Templates) > Windows 元件 (Windows Components) > 遠端桌面服務 (Remote Desktop Services) > 遠端桌面連線用戶端 (Remote Desktop Connection Client)
3. 在右側面板中找到 「關閉用戶端的 UDP (Turn off UDP on client)」 設定項目，點擊兩下開啟。
4. 將狀態切換為 「已啟用 (Enabled)」，然後點擊「確定」儲存設定。

為什麼這樣做有效？

預設情況下，現代 Windows 的 RDP 會同時使用 TCP 與 UDP 進行傳輸。當網路環境對 UDP 封包處理不佳（例如 QoS 限制、防火牆攔截或 NAT 問題）時，連線品質就會大幅下降。關閉 UDP 後，遠端桌面會強制回退到純 TCP 模式，雖然延遲可能會微幅增加，但連線的穩定度與抗干擾能力會大幅提升。

提示：設定完成後，建議重新啟動「遠端桌面連線」軟體或直接重啟電腦以確保設定生效。

how to connect codex app to remote ollama backend through caddy relay

如何讓 Codex App 連接公司架設的 LLM

從 Caddy 閘道安裝、遠端 Ollama API 金鑰，到 Codex 的 config.toml 組態設定，一次整理成可直接照做的流程。

前言

OpenAI 提供免費下載的 Codex 系列代理軟體（Agent Software），其中分成 文字命令列版 Codex CLI ，及桌機應用版 Codex App，或稱 Codex Desktop。 兩者皆可代理操作電腦，自動完成眾多工作。 Codex 預設使用 OpenAI 收費的大語言模型（LLM），但允許接到外部架設的語言模型。

由於外部語言模型眾多，最穩定的做法不是直接讓 Codex 連接遠端服務，而是先在本機安裝一個中介閘道（gateway)。此時，建議用免費的 Caddy 閘道軟體，將本機作為中繼站 (relay)，把 Codex 送給 http://localhost:11434 的請求，對外轉送到一台支援 /v1/responses 請求的遠端 Ollama 伺服器。下面範例的 IP 與主機名稱已匿名化，請自行替換成公司實際值。

如果自己電腦夠強， Ollama 服務已經在本機 localhost:11434 運行且無需 API 金鑰，則請直接跳過 Caddy 相關步驟，設定讓 Codex 直接連本機即可。但如果打算用公司遠端 Ollama 服務，則 Caddy 可以將本地請求轉發到遠地服務端點，並在轉發時自動加入遠端的 API 金鑰。

整體思路很簡單：

1. 若本機未安裝 Ollama 服務，先安裝 Caddy 中介閘道，設定 Caddyfile 組態檔，於本機 11434 埠號，轉送請求到遠端 Ollama。
2. 準備 Caddy 啟動腳本，方便啟動閘道。
3. 安裝 Codex App，設定 ~/.codex/config.toml 組態檔，設定本機閘道位置與採用模型。

1a. 安裝 Caddy 閘道服務 🔧

Caddy 支援 Windows、macOS 與 Linux 三種平台。以下分別說明：

Windows

使用 Chocolatey 安裝，或手動下載官方安裝檔：

# 使用 Chocolatey（需管理員權限）
> choco install caddy

# 或手動下載：https://caddyserver.com/download?platform=windows&plugins=reverse_proxy

macOS

使用 Homebrew 安裝：

> brew install caddy

Linux（Ubuntu / Debian）

使用官方腳本一鍵安裝：含更新套件，安裝倉庫金鑰，從倉庫下載 caddy

> sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
> curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
> curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
> sudo apt update
> sudo apt install caddy

安裝完成後，所有平台都可以用以下指令確認版本：

> caddy version

1b. 建立 Caddy 組態檔

假設公司 Ollama 伺服器提供 OpenAI 相容服務，並且需要 API 金鑰。則可建立如下 Caddyfile 組態檔：其中，reverse_proxy 標示多對一的反向代理區塊。

:11434 {
  bind 127.0.0.1 [::1]
  reverse_proxy <REMOTE_IP>:443 {
    header_up Host <REMOTE_HOST>
    header_up Authorization "Bearer YOUR_API_KEY"
    header_up X-Forwarded-Proto https
    transport http {
      tls
      tls_insecure_skip_verify
    }
  }
}

這裡的重點是：localhost:11434 代表 Codex 只要連接本機埠號即可，真正的遠端網址與認證都由 Caddy 處理。

其中，REMOTE_IP 填入公司 Ollama 伺服器 IP，REMOTE_HOST 填入公司 Ollama 伺服器域名。若反向代理或TLS握手出問題，header_up Host <REMOTE_HOST> 亦可不寫死，改成 header_up Host {upstream_hostport}。若伺服器使用自簽憑證，加入 tls_insecure_skip_verify 也能避免 TLS 驗證失敗。

2. 準備 Caddy 啟動腳本 🚀

如下以 macOS 及 Linux 平台常見的 bash 腳本語言為例。此腳本利用 caddy 指令，依照 caddyfile 格式，讀入 ./Caddyfile 組態檔，執行閘道轉送工作。至於Windows 用戶，則可直接在 PowerShell 執行 caddy start --config ./Caddyfile，以自動在背景執行。

#!/usr/bin/env bash
set -euo pipefail

nohup caddy run --config ./Caddyfile --adapter caddyfile > /tmp/caddy.log 2>&1 &

如果 Caddy 已經有 autosave.json 或舊設定干擾，記得先清掉，否則 Caddy 可能載入到舊的 host match，導致看起來像「有啟動但沒回應」。

3a. 安裝 Codex App

安裝 Codex App 後，先確認是否正常啟動。

然後，目標是讓 Codex 透過組態檔，使用本地閘道，選用語言模型。

3b. 編輯 ~/.codex/config.toml 組態檔 🧩

如下設定範例把模型提供者指向本機的 Caddy 閘道，並讓 Codex 走 /v1 這種 OpenAI 相容 API 格式。

model = "qwen3.6:35b-a3b-q8_0"
model_provider = "my-caddy-gateway"

[model_providers.my-caddy-gateway]
  name = "Custom Gateway"
  base_url = "http://localhost:11434/v1"
  api_key = "not-empty"
  wire_api = "responses"
  openai_compatibility_fallback = true

model

指定要使用的模型名稱，必須跟遠端 Ollama 服務支援的模型一致。

base_url

指向本機的 Caddy 閘道位置，而不是直接連接遠端伺服器。

wire_api

如果遠端 Ollama 服務支援 /v1/responses，這個設定通常最合適。

4. 驗證連線 ✅

完成設定後，可以先用 curl 網頁請求工具，測試本機 11434 埠號是否通到遠端 LLM：

curl -s http://localhost:11434/v1/models
curl -s http://localhost:11434/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer not-empty" \
  -d '{
    "model": "qwen3.6:35b-a3b-q8_0",
    "input": "Say hello in one word",
    "stream": false
  }'

如果看到回應裡面有 Via: 1.1 Caddy，而且回傳的模型名稱正確，就代表本機中繼服務 與遠端 Ollama 已經接起來了。

5. 啟動 Codex App

最後一步就是啟動 Codex App，選用剛剛設定好的組態檔：

codex app ~/Documents/Codex

剛才的啟動腳本，也可以在啟動 Caddy 閘道後，再開啟 Codex App，帶上初始工作目錄。只要 http://localhost:11434/v1 能正常回應，Codex 就會透過這個埠號 11434，使用遠端模型。

常見問題

Q：為什麼 Codex 明明有連上，但回應看起來像空的？

A：有些模型會把內容放在 reasoning 或其他欄位，而不是 content。另外如果 max_tokens 太小，也可能只拿到半截輸出。

Q：如果 Caddy 起來了但沒有轉發怎麼辦？

A：先檢查 autosave.json 是否有舊設定，再確認 Host、TLS 與 金鑰正確否。

注意事項

Ollama 實作的 /v1/responses 介面僅支援無狀態（non-stateful）請求。以下欄位雖然可以傳入以維持相容性，但 Ollama 伺服器並不會實際使用這些欄位，來維護對話狀態：

• previous_response_id — 不會用於追蹤歷史回應。
• conversation — 不會用於維護伺服器端的對話上下文。

這表示每次請求都是獨立的。如果需要多輪對話，必須在客戶端（如 Codex App）自行管理對話歷史，並將完整的訊息列表傳給 Ollama。

結語

把 Codex App 接到本地 LLM 的核心，其實就是「閘道」建置，與「組態」設定。Caddy 閘道負責把流量轉到遠端 Ollama，Codex 只要知道本機的 base_url 閘道位置即可。這樣做的好處是設定清楚、可除錯，也比較容易切換不同後台及語言模型。

a comparison table about disk scheduling algorithms

🚀 四種硬碟排班演算法 (SCAN, LOOK, C-SCAN, C-LOOK) 對比

在作業系統中，硬碟排班 (Disk Scheduling) 的目標是減少磁頭移動的總距離，以縮短磁軌請求的總服務時間。其中，面對 SCAN、LOOK 及其循環變體 C-SCAN 與 C-LOOK，許多初學者常感到混淆。本文透過「服務方向」與「回頭策略」兩個維度，將其整理為 2x2 表格，幫助大家一目瞭然。📖

		🎯 回頭策略 (磁頭移動方向的回轉時機)
		🏁 軌道兩端終點 (遇磁軌編號 0 或 Max)	👀 目前方向最後請求 (Look-ahead)
🛠️ 服務方向	↔️ 雙向服務 (上下行方向皆提供服務)	🏗️ SCAN 運作： 磁頭來回服務。不論有無請求，皆須到達磁碟實體邊緣才轉向。 ※ 特色：每層都巡，且坐到底。	🔎 LOOK 運作： 磁頭來回服務。若目前方向前方已無請求，即刻轉向。 ※ 特色：上方沒人按就不會坐到頂。又稱電梯演算法。
	🔄 單向循環 (限定上行或下行才提供服務)	🎡 C-SCAN 運作： 僅單向服務。到達物理端點後立即跳回起點，跳轉期間不服務。 ※ 特色： 確保所有軌道請求的等待時間均勻一致。	✨ C-LOOK 運作： 僅單向服務。服務完最後請求後，即跳回另一端首個請求。 ※ 特色：結合公平性與高效率，實務最推薦。

📊 小結

• 回頭策略差異： 端點模式 (SCAN 系列) 邏輯簡單，雖有空跑現象，但適合重負載均勻分布情形；最後請求模式 (LOOK 系列) 效率較高。
• 服務方向差異： 雙向服務會出現中間磁軌的掃描頻率高於兩端；單向循環 (C 系列) 則提供了最佳的「公平性」。

When to use Java String, StringBuffer, or StringBuilder?

在 Java 開發中，處理文字字串是最常見的操作之一。然而，許多初學者仍容易混淆 String、StringBuffer 與 StringBuilder 的使用時機。

選擇錯誤的工具不僅會影響程式的執行效率（Performance），在多執行緒環境下更可能導致難以追蹤的 Bug。為了幫助大家徹底釐清這三者的差異，以下整理了一份綜合比較表，從底層架構到實際應用一目了然。

比較特性	String	StringBuffer	StringBuilder
可變性 (Mutability)	不可變 (Immutable)	可變 (Mutable)	可變 (Mutable)
執行緒安全	安全	安全 (synchronized)	不安全
效能速度	最慢	居中	最快
修改方式	產生新物件	原地修改 (Buffer)	原地修改 (Buffer)
主要操作方法	concat(), split(), substring(), +	append(), insert(), delete(), reverse()	append(), insert(), delete(), reverse()
方法傳回值	傳回新 String	傳回 this	傳回 this
儲存位置	字串池 / Heap	Heap	Heap
引入版本	Java 1.0	Java 1.0	Java 1.5

總結與建議

總結來說，這三者的選擇邏輯非常清晰：

• 如果處理的是少量數據，或者字串內容不會改變，請直接使用 String。
• 如果須進行大量字串拼接（例如迴圈中組裝 SQL 或 JSON），且僅在單一執行緒中運行，StringBuilder 是最佳選擇。
• 只有在明確需要多執行緒共享同一個可變字串時，才考慮使用 StringBuffer。

掌握以上細節，不僅能讓程式碼跑得更快，也能展現 Java 記憶體管理與並行控制的專業理解。希望這份表格對您的開發工作有所幫助！

quick ways to initialize a list of numbers or strings in java

Java 快速建立整數與字串清單的寫法

在 Java 中，建立 List<Integer> 與 List<String> 是非常常見的需求。 以下依照不同 JDK 版本，整理出幾種快速建立可修改（modifiable） 清單的寫法，可依個人習慣彈性使用。

1️⃣ JDK 5（2004）起支援的寫法

自 JDK 5 起，Java 引入了 泛型（Generics） 與 自動封裝（Autoboxing），因此可以直接將 int 自動轉為 Integer。

  Integer[] intArray = {1, 2, 3};
  String[]  strArray = {"A", "B", "C"};

  List<Integer> ints =
    new ArrayList<Integer>(Arrays.asList(intArray));

  List<String> strings =
    new ArrayList<String>(Arrays.asList(strArray));
  

✅ 適用於舊版系統（JDK 5 / 6）
✅ 清楚明確，但型別宣告較冗長

2️⃣ JDK 7（2011）起支援的寫法（鑽石運算子）

JDK 7 引入了 鑽石運算子（<>）， 可讓編譯器自動推斷泛型型別，使程式碼更精簡。

  List<Integer> ints =
    new ArrayList<>(Arrays.asList(1, 2, 3));

  List<String> strings =
    new ArrayList<>(Arrays.asList("A", "B"));
  

✅ 語法更簡潔
✅ 仍然回傳可修改的 ArrayList

3️⃣ Java 9（2017）起支援的寫法（搭配 List.of）

Java 9 引入了 List.of() 作為集合工廠方法， 可快速建立不可修改的清單。 若實務上仍需要可修改的清單，可再包裝成 ArrayList。

  List<Integer> ints =
    new ArrayList<>(List.of(1, 2, 3));

  List<String> strings =
    new ArrayList<>(List.of("A", "B"));
  

✅ 語意清楚、現代化寫法
⚠️ List.of() 本身不可修改，需額外包裝

✅ 小結

• JDK 5+：可使用泛型與自動封裝
• JDK 7+：可使用鑽石運算子，讓程式碼更乾淨
• Java 9+：可搭配 List.of() 撰寫更語意化的程式碼

實務上建議：
👉 需要可修改清單 ⇒ 使用 new ArrayList<>(...)
👉 元素固定不變 ⇒ 直接使用 List.of()

compare java wait/notify synchronization with lock or condition in java.util.concurrent (juc)

為什麼 Java 的 wait/notify 逐漸被新 API 取代？

在 Java 的演進過程中，雖然 Object.wait() 與 Object.notify() 仍存在於核心庫中，但在現代開發場景，java.util.concurrent (JUC) 提供的 Lock 與 Condition 已成為主流。以下是三大核心取代原因：

1. 靈活性與精確控制 (Multiple Conditions)

這是最關鍵的進步。舊有機制中，每個物件僅有一個「等待集」。

• 舊機制： 生產者與消費者共用同一個等待隊列。呼叫 notify() 無法指定喚醒誰，常被迫改用 notifyAll()，導致驚群效應 (Thundering Herd)。
• 新機制 (Condition)： 一個鎖可建立多個條件物件（如 notFull, notEmpty）。生產者只需喚醒消費者，反之亦然，效能大幅提升。

2. 安全性與健壯性 (Robustness)

新 API 解決了許多語法上的僵化問題：

特性	Object.wait/notify	JUC Condition
鎖的依賴	強烈耦合 synchronized	配合 ReentrantLock，更靈活
中斷響應	僅支援基本中斷	支援不可中斷的等待 (awaitUninterruptibly)
超時控制	毫秒級	精確至奈米級 (nanoseconds)

3. 功能擴展性 (Advanced Features)

ReentrantLock 提供了舊機制無法達成的進階功能：

公平性 (Fairness)： 新 API 支援公平鎖設定，確保等待最久的執行緒優先獲取資源。
非阻塞嘗試： 透過 tryLock()，執行緒可以在拿不到鎖時立即返回，避免死等。

總結：除非是極簡的同步邏輯，否則在現代 Java 開發中，ReentrantLock + Condition 是更安全、高效的選擇。

choose which S3 object ownership?

S3 Object Ownership 兩種模式差異

Amazon S3 服務全名為 簡單儲存服務 (Simple Storage Service)，可支援存取放置於AWS公有雲的檔案，其服務類似 Google Drive 或 Microsoft OneDrive 的網碟功能。S3 儲存容器稱為水桶，儲存的檔案稱為物件。

建立S3水桶時，須決定上傳到水桶的物件，其擁有者將自動歸屬於誰，稱為物件擁有權（Object Ownership）設定。只有物件的擁有者才能設定物件的存取權。這裡簡單介紹兩種設定模式的差異：

🔒 模式一：ACL disabled（recommended）

所有物件都由 Bucket 擁有者持有，不論是誰上傳。ACL 完全被停用，不能再用 ACL 來授權。存取控制只能透過 IAM Policy 或 Bucket Policy 來設定。

優點：集中管理，避免跨帳號物件所有權混亂。

最佳實務：AWS 建議使用這種模式，因為更安全、更容易維護。

🔑 模式二：ACLs enabled

物件可能由上傳者帳號持有，而不是 Bucket 擁有者。存取控制可以透過 ACL（物件或 Bucket 層級）來設定。Bucket Policy 仍然可以使用，但 ACL 會一起參與判斷。

用途：適合跨帳號上傳的特殊情境，例如合作夥伴需要保有自己上傳檔案的所有權。

缺點：管理較複雜，容易造成權限混亂。

⚡ 簡單比較
模式	     物件擁有者	                存取控制方式	      AWS 建議
ACL Disabled Bucket 擁有者	        Policy（IAM / Bucket）✅ 建議
ACL Enabled  上傳者帳號可能成為物件擁有者  ACL + Policy	      僅限特殊需求

✍️ 結語

如果你的環境需要簡單、集中、安全的存取管理，選擇 ACL Disabled（Bucket owner enforced） 是最佳做法。 只有在跨帳號物件所有權的特殊需求下，才需要考慮 ACL Enabled。

註: S3 權限管理機制比較：ACL vs. 水桶政策

功能特性	S3 ACL (存取控制清單)，舊版	水桶政策 (Bucket Policy)，新版
物件所有權	預設由「上傳者」擁有物件，即使上傳者不是水桶擁有者。	由「水桶擁有者」自動擁有水桶內的所有物件。
設定格式	XML 格式。	JSON 格式。
控制粒度	可針對「單一物件」進行微調。	針對整個水桶或特定「前綴 (Prefix/資料夾)」進行管理。
權限複雜度	僅限基本權限（讀取、寫入、完全控制），不支援「拒絕 (Deny)」。	支援複雜條件（IP 限制、MFA、特定時間、明確拒絕等）。
稽核便利性	低。必須逐一檢查每個物件的 ACL 才能得知誰有存取權。	高。只需查看一個 JSON 文件即可瞭解全域權限。
AWS 建議實務	不建議使用（除了特定日誌寫入需求）。	強烈建議使用（最佳實務）。

how to deal with metric scale inconsistency in topn recommendation evaluation

🎯 推薦系統一般會回傳前 N 個排名的物品清單給用戶，稱為 Top‑N 推薦。 遇到推薦模型須要訓練及評估時，習慣先蒐集用戶與物品的互動資料，再將資料拆分成沒有重疊的訓練集及測試集。 模型在訓練時只看得到訓練集，評估時則拿測試集作為驗證的標準答案，以免作弊。

通常，在評估推薦模型時，和一般機器學習的模型評估不同，會採用逐用戶等比例切割 (userwise stratified split) 評估法。 即針對每個用戶的喜好物品，等比例拆分成訓練集及測試集，請模型利用全體訓練集作出該用戶的 Top‑N 推薦，然後利用其個人測試集作核對，計算該用戶的得分指標。 因為模型未看過測試集，所以最後全體用戶的指標平均值就是模型的客觀表現，可供比較之用。

上述作法在實際計算得分指標時，常遇到測試集數量和推薦數量 N 不匹配，造成得分指標尺規不一致的困擾。以下進行問題，原理，及解法說明。

❓ 問題介紹

在 逐用戶等比例切割 的設定下，每位用戶的測試集互動數量不一樣。 當使用固定的 Top‑N 推薦清單做評估時，就會出現「測試集大小與 Top‑N 回傳數量不匹配」的情況：

• 👤 輕度互動的用戶：測試集互動數 |Rᵤ| < N
• 👥 重度互動的用戶：測試集互動數 |Rᵤ| > N

這會讓 回傳數量 N 的精確率 Precision@N，及回傳數量 N 的召回率 Recall@N 產生尺規上限受限的現象， 影響不同用戶之間評比的尺規公平性。

🔍 原理說明（為什麼會不公平）

若使用 Top‑N 評估，指標的分母固定或依用戶而變：

• Precision@N ＝ 命中數 / N，其分母固定為 N， 輕度互動用戶的精確率最大值會受此尺規「天花板」限制，達不到 1.0。
• Recall@N ＝ 命中數 / |Rᵤ|，其分母為 |Rᵤ|， 重度互動用戶的召回率最大值會受此尺規「天花板」限制，達不到 1.0。

這並非「計算錯誤」，而是 Top‑N 回傳量的本質所導致的評估上限不一致。

相比之下，✨正規化打折累積增益 NDCG@N 指標會以用戶理想排序的 理想打折累積增益 IDCG 進行正規化， 而 IDCG 的長度是 min(|Rᵤ|, N)。因此每位用戶都能達到 1.0 的尺規滿分， 不會因為測試集大小不同而被系統性壓低。

💡 實務解法

以下是最常見的三種解決做法：

1. ✅ 接受個別用戶的指標尺規上限不同：只要所有模型都在相同的尺規限制下比較，排名仍有參考價值。 因為各模型可在相同受限指標尺規範圍內求好表現，所以不影響依據指標平均值所作的模型排名比較。
2. 📋 粗糙解法：改用留1筆 Leave‑One‑Out（LOO）分割法，每位用戶只保留一筆測試互動，再搭配 命中率 Hit Rate (HR@N) ＝ 命中數 指標作評估， 其值為 0 或 1。
3. ⭐ 精細解法：改以 NDCG@N 作為主指標，並輔以 Precision/Recall/HR， 讓輕重度互動的用戶都能公平比較。

start versus restart for docker containers

Docker start vs restart：快速掌握差異

Docker 是個方便的服務部署工具，可快速安裝執行伺服軟體，供瀏覽器等前台使用。當用戶從 docker 映像檔建立 (create) 及啟動 (start) 容器時，容器將分別處於 巳建立 (created) 及 執行 (running) 狀態。然後，遇到執行意外出錯 或 管理者故意下停止指令 (docker stop) 時，容器將進入退出 (exited) 狀態。

處於退出狀態的容器，因行程退出，將喪失記憶體狀態，但仍保有原來的可寫層 (writable layer) ，即儲存體狀態。此時，兩種指令 docker start 與 docker restart 都能讓既有容器，從現有可寫層狀態，再跑起來，效果完全一樣。以下用表格整理說明兩指令適用時機之差異。

1. 指令行為比較

指令	行為說明	適用狀態
docker start	啟動 巳建立 (created) 及退出 (exited) 的既有容器，直接執行其進入點命令 (entrypoint command)	created / exited
docker restart	同上，但遇到執行狀態的容器會先讓其 stop，再 start	created / running / exited

2. 執行期影響比較

項目	start	restart
送 SIGTERM / SIGKILL	❌	✅
PID 改變	❌	✅
記憶體狀態重置	❌	✅
中斷連線	❌	✅
停機時間	無	短暫

3. docker restart 的清理範圍

區域	是否清理
In-memory data	✅
Processes / threads	✅
Open sockets	✅
TCP connections	✅
Writable filesystem	❌
Volumes	❌
Env / config	❌
Image	❌

4. 結論：適用性與效果

docker start 與 docker restart 兩個指令目的都在不放棄既有容器的可寫層之下，以新記憶體，執行容器的服務。在容器處於 退出 狀態時，兩者效果完全相同，都會重新啟動容器主行程，重新分配記憶體，並執行 entrypoint command。 其適用時機摘要如下表。

適用情境	效果
容器正常退出，要再跑一次	docker start 就現有可寫層，啟動既有容器
程式卡住、連線異常	docker restart 保留可寫層，重新啟動既有容器
組態設定或資料壞掉	docker run 放棄可寫層，重新建立啟動新容器

Linked Lists from C to Java

「C Pointer Concepts in Java」一文提到 Java 沒有指標型別 (pointer type) ，但有參照型別 (reference type) 的設計。在遇到須要處理鏈結清單 (linked list)、圖形 (graph) 等資料結構時，Java 如何透過參照型別，仍能達成類似的效果。本文將以「鏈結清單」為例，分別用 C 與 Java 實作，說明兩者的差異與對應。

---

🔹 C 語言：使用指標建立鏈結清單

/*
   1 -> 2 -> 3 NULL
*/
#include <stdio.h>
#include <stdlib.h>

// 定義節點結構
typedef struct Node {
    int data;  // 資料
    struct Node* next;  // 下一節點指標
} Node;

int main() {
    // 建立三個節點
    Node* head = (Node*)malloc(sizeof(Node));
    Node* second = (Node*)malloc(sizeof(Node));
    Node* third = (Node*)malloc(sizeof(Node));

    // 給值與連結
    head->data = 1;
    head->next = second;

    second->data = 2;
    second->next = third;

    third->data = 3;
    third->next = NULL;

    // 印出鏈結清單
    Node* current = head;
    while (current != NULL) {
        printf("%d -> ", current->data);
        current = current->next;
    }
    printf("NULL\n");

    return 0;
}

其中，
• Node* 是指標變數，指向記憶體中的節點。
• 使用 malloc 配置記憶體，並用 -> 操作指標指向的內容。
• 每個節點透過 next 指向下一個節點，形成鏈結。

---

🔹 Java 語言：使用參照建立鏈結清單

/*
   1 -> 2 -> 3 null
*/

// 定義節點結構
class Node {
    int data; // 資料
    Node next;  // 下一節點參照

    Node(int data) {
        this.data = data;
        this.next = null;
    }
}

public class LinkedListDemo {
    public static void main(String[] args) {
        // 建立三個節點
        Node head = new Node(1);
        Node second = new Node(2);
        Node third = new Node(3);

        // 給值與連結
        head.next = second;
        second.next = third;

        // 印出鏈結清單
        Node current = head;
        while (current != null) {
            System.out.print(current.data + " -> ");
            current = current.next;
        }
        System.out.println("null");
    }
}

其中，
• Node 是一個類別，變數如 head、second 是參照變數，指向物件。
• 使用 new 建立物件，並透過 . 操作物件的屬性。
• 雖然語法上沒有 * 或 &，但物件的參照本質上就像 C 的指標。

---

🔄 對照總結：C 指標 vs Java 參照

概念	C 語言	Java 語言
記憶體操作	明確使用 * 和 &	隱含於物件參照
記憶體配置	malloc	new
節點連結	指標指向下一節點	物件參照指向下一節點
安全性	容易出現記憶體錯誤	自動垃圾回收記憶體管理 (GC)

以上說明 Java 雖然沒有指標型別，但仍能透過「參照型別」的設計，實現如鏈結清單這類需要動態記憶體與節點連結的資料結構。希望對於從 C 過渡到 Java 的學習者有幫助。