FlickrProxy #4 - 修正同步上傳的問題

問題與答案 (FAQ)

Q&A 類別 A: 概念理解類

A-Q1: 什麼是 FlickrProxy 專案？

• A簡: FlickrProxy 於圖片首次請求時上傳至 Flickr，完成後重導至 Flickr，藉此節省網站頻寬並集中託管影像。
• A詳: FlickrProxy 是一個以 ASP.NET 實作的影像代理服務。當圖片首次被請求時，伺服器偵測本地端快取資訊是否存在，若無則上傳該圖至 Flickr，並建立對應快取資訊；上傳完成後將使用者重導向 Flickr 圖片連結。此設計可降低自家主機的儲存與頻寬負擔，但需要妥善處理併發請求、避免重複上傳與效能衝突，文中以臨界區、鍵控鎖及信號量改善這些問題。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, A-Q3, B-Q1

A-Q2: 為何會發生重複上傳到 Flickr 的問題？

• A簡: 同一張圖在首次請求期間，若有多個請求同時抵達，會同時觸發上傳，導致重複上傳。
• A詳: 問題源於典型的競爭條件：系統在檢查「快取資訊檔是否存在」與「建立快取/上傳」間缺乏互斥保護。兩個以上相近時間的請求都判定「尚未上傳」，因此各自啟動上傳流程。為避免重複上傳，必須將「判斷是否需上傳」與「建立 Flickr 副本檔」置於同一臨界區中，並以適當粒度的鎖來保護。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q3, A-Q23, B-Q7

A-Q3: 什麼是臨界區（Critical Section）？

• A簡: 需被互斥保護的程式區段，確保同時間只有一個執行緒進入。
• A詳: 臨界區是指對共享資源進行存取的關鍵程式片段，若未互斥保護，將導致競爭條件而出現狀態不一致。以 FlickrProxy 為例，「判斷是否需要上傳」和「建立 Flickr 副本檔」必須同時被鎖住，確保同一時間只有一個請求執行這兩步，避免重複上傳與錯誤的快取狀態。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, B-Q7, B-Q8

A-Q4: 在 ASP.NET 中 lock 是什麼？為何使用？

• A簡: C# lock 基於 Monitor 提供互斥，避免共享狀態於多執行緒下被競爭破壞。
• A詳: C# 的 lock 語法糖包裹 Monitor.Enter/Exit，確保臨界區同時間只允許單一執行緒進入。於 ASP.NET 中，請求並行來自 ThreadPool，不當共享存取（如檔案/快取檢查與建立）會產生競態。lock 可保護關鍵段落，維持資料一致與操作的原子性，但需小心鎖的粒度與鎖物件選擇，避免效能劣化或死鎖。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q5, A-Q6, B-Q10

A-Q5: lock 範圍過大會有什麼影響？

• A簡: 鎖太大會序列化本可並行的請求，造成吞吐下降、延遲升高。
• A詳: 鎖定過大的臨界區會讓彼此獨立、不需競爭的工作也被迫排隊，導致 CPU 核心閒置及整體吞吐降低。首版以 lock(this.GetType()) 將所有涉及上傳的請求都鎖住，結果是不同照片也互相阻塞。應縮小臨界區與鎖影響範圍，只鎖需要一致性的最小集合，並採鍵控鎖以降低爭用。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q6, A-Q8, B-Q8

A-Q6: 什麼是鎖的粒度（Lock Granularity）？

• A簡: 指鎖保護範圍大小。粒度越細，並行度越高，管理難度也上升。
• A詳: 粗粒度鎖易於理解與實作，但會降低並行度；細粒度鎖能提升吞吐與資源利用，但需更精確界定共享狀態與一致性邊界。在 FlickrProxy 中，從全域類型鎖到「每張照片」鎖，便是從粗到細的粒度調整，藉此讓不同圖片請求互不影響。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q5, A-Q7, B-Q25

A-Q7: 為何要對同一張照片的請求才上鎖？

• A簡: 只有同一資源的請求共享狀態，彼此才需互斥；不同資源應可並行。
• A詳: 鎖的目的是保護共享狀態一致性。對 FlickrProxy 而言，同一張照片的「是否已上傳」與「快取資訊檔」是共享狀態；不同照片沒有共享該狀態，無須相互阻塞。因此採鍵控鎖（每張照片一把鎖）可避免不必要的排隊，提高併發處理效率。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q10, B-Q3, B-Q11

A-Q8: lock(this.GetType()) 與 lock(專屬物件) 的差異？

• A簡: 前者全域共用，會互相阻塞；後者依資源鍵分離，僅影響同資源請求。
• A詳: 以類型物件作鎖等於所有該類別實例共用同一把鎖，導致不同圖片請求也被序列化。改為針對每張照片擁有一個獨立鎖物件（透過字典對應），即可將競爭範圍縮到僅同一資源，顯著降低鎖爭用與等待時間。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q5, A-Q7, B-Q3

A-Q9: 為何不建議以字串或 FileInfo 當 lock 物件？

• A簡: 字串有內插（intern）與外部可見風險；FileInfo 物件不具唯一性保證。
• A詳: 鎖物件應私有且僅內部持有。字串可能因內插而共用同一實例，或被外部鎖住引發死鎖；FileInfo 的等值不代表參考同一物件，不適合作為鎖鍵。更安全的做法是自建私有物件並以鍵（如雜湊或正規化路徑）映射取得。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q14, B-Q16

A-Q10: 什麼是鍵控鎖（Keyed Locking）？

• A簡: 以資源鍵對應到專屬鎖物件，只鎖同鍵的操作，提升並行度。
• A詳: 鍵控鎖是一種將鎖與資源鍵（如檔名或雜湊）建立一對一映射的手法。當操作某資源時，先取回該鍵對應的鎖物件，再進入臨界區。如此僅同一鍵的請求會互斥，其他鍵可同時進行，兼顧一致性與吞吐。實務可用（Concurrent）Dictionary + GetOrAdd 實現。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q7, B-Q16, C-Q1

A-Q11: LockHandle 的核心角色是什麼？

• A簡: 依照片鍵取得唯一鎖物件，讓同一照片請求互斥、不同照片並行。
• A詳: LockHandle 屬性負責計算照片鍵（文中用 MD5），再在全域字典中取得或建立該鍵的私有鎖物件。呼叫端以 lock(LockHandle) 包覆臨界區，確保「檢查快取→建立快取」在同一張照片上不被並發破壞。這是鍵控鎖實作的核心元素。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q4, B-Q6, C-Q1

A-Q12: 為何要用 MD5 作為檔案識別鍵？

• A簡: MD5 可提供高機率唯一鍵，避免路徑大小寫與別名問題，但有成本。
• A詳: 使用檔案內容的 MD5 可穩定識別圖檔，即便路徑或大小寫不同也能對應同一內容；在系統已有 MD5 計算需求時順手使用更方便。不過計算成本不低，對大量檔案可能造成 CPU 壓力，替代方法是使用正規化路徑搭配不區分大小寫比較。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q13, B-Q21, C-Q6

A-Q13: 使用正規化路徑取代 MD5 的可行性？

• A簡: 可用完整路徑與大小寫正規化當鍵，省去雜湊成本但需小心符號連結等情境。
• A詳: 以 Path.GetFullPath 取得絕對路徑，搭配 StringComparer.OrdinalIgnoreCase 的字典，能在 Windows 上避免大小寫差異。若存在捷徑、符號連結或多掛載點，需要額外正規化策略。其優點是省 CPU，缺點是在內容變動但路徑不變時需同步處理快取失效。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q12, C-Q6

A-Q14: Dictionary 作為鎖物件容器的優缺點？

• A簡: 簡單高效，但需處理多執行緒存取安全與潛在成長不控問題。
• A詳: Dictionary 取用 O(1) 且易於鍵控鎖實作；然而多執行緒情境需以 lock 保護增刪，或改用 ConcurrentDictionary。隨請求增加鍵可能無上限成長，應考慮移除策略（弱參考、快取過期）與記憶體觀測，以避免長期運行造成壓力。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q15, B-Q16

A-Q15: 什麼是信號量（Semaphore）？

• A簡: 一種計數型同步原語，限制同時進入臨界區的執行緒數量。
• A詳: 信號量維護一個可用計數，WaitOne 取得資源、Release 歸還資源。當計數為 0 時，新的等待者需阻塞。相較 lock 的「最多一位」互斥，信號量可設定「同時 N 位」，用於控制上傳等昂貴作業的並行度，避免過度壓載外部服務或本機資源。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q16, B-Q9, C-Q3

A-Q16: lock 與 Semaphore 有何差異？

• A簡: lock 為互斥（一位），Semaphore 為計數控制（多位）；用途與特性不同。
• A詳: lock（Monitor）保證同時間僅一執行緒進入臨界區，適合保護共享狀態一致性；Semaphore 可允許指定數量並行，適合節流昂貴或外部相依操作。兩者可搭配：用 lock 確保不重複上傳，用 Semaphore 限制同時上傳數，兼顧正確性與穩定性。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q15, B-Q11

A-Q17: 為何需要限制同時上傳數量？

• A簡: 避免頻寬被耗盡、外部 API 節流或風險控管觸發，維持穩定吞吐。
• A詳: 多圖同時首次請求會引發並行上傳。若不節流，可能導致上傳失敗率上升、外部服務限速或封鎖、以及自身 ThreadPool 被阻塞。以 Semaphore 限制並行數（如 2 個），可在可接受延遲內，平衡資源使用與成功率。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q9, C-Q3

A-Q18: 二元信號量與計數信號量差別？

• A簡: 二元僅 0/1，如互斥鎖；計數可 >1，允許多個並行進入。
• A詳: 二元信號量行為近似於互斥鎖，但不具重入語意；計數信號量可設定並行上限值（例：2），常用於控流。選擇取決於需求：只允許單一並行可用 lock；若需 N 個並行，計數信號量更合適。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q15, A-Q16

A-Q19: 為何在 ASP.NET 中避免長時間阻塞？

• A簡: 會占用 ThreadPool 執行緒，造成延遲、併發下降與資源饑荒。
• A詳: ASP.NET 使用 ThreadPool 處理請求。若以同步 I/O 與阻塞式等待長時間佔用執行緒，將減少可用執行緒，降低整體併發度。建議將 I/O 改為非同步（SemaphoreSlim + async/await）或縮短臨界區，減輕 ThreadPool 壓力，避免雪崩效應。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q12, B-Q19, C-Q5

A-Q20: X-FlickrProxy 回應標頭的用途？

• A簡: 標示此次請求觸發了上傳動作，利於除錯與觀測。
• A詳: 當首次請求導致上傳時，系統在回應加上 X-FlickrProxy: Upload。此自訂標頭有助於檢測是否為首次上傳、統計上傳比例、與快速定位性能尖峰或併發問題，是實務上打造可觀測性的簡單手段。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q24, C-Q9

A-Q21: 什麼是請求合併（Single-flight）？

• A簡: 多個對同資源的同時請求僅執行一次實際工作，其他共享結果。
• A詳: Single-flight 透過鎖或協調結構，將同資源的同時請求「合併」為一次執行，其他等待結果後共用成果。於 FlickrProxy，即為同張照片同時首次請求只上傳一次，其他請求等待快取建立完即重導，避免重工與浪費。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q7, B-Q11, C-Q1

A-Q22: 為何「只鎖必要區段」很重要？

• A簡: 減少鎖持有時間與競爭，提升吞吐，降低延遲與死鎖風險。
• A詳: 鎖持有越久，被阻塞的工作越多；將不需一致性的操作移出臨界區可增加並行。對 FlickrProxy，臨界區僅含「是否需要上傳的判定」與「建立副本檔」；昂貴 I/O 或外部呼叫可在信號量下進行，避免鎖內等待造成放大效應。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q5, B-Q8, B-Q25

A-Q23: 什麼是競爭條件（Race Condition）？

• A簡: 多執行緒非原子存取共享狀態，導致執行順序不同產生不一致結果。
• A詳: 當程式依賴「檢查再行動」的時機與順序，若缺乏互斥或原子性，則兩個請求可能同時看到同一狀態並各自行動，造成重複或錯誤。在 FlickrProxy 中，兩個請求同時判斷未上傳並各自上傳即是典型案例。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q3, B-Q7

A-Q24: 為何全域鎖會造成請求互相影響？

• A簡: 全域鎖讓不相關資源共用同一鎖，彼此進入臨界區需排隊。
• A詳: 全域鎖如 lock(this.GetType()) 將所有上傳相關請求納入同一互斥，導致不同圖片下載也互相等待。最終使系統吞吐取決於最慢的上傳，極不經濟。採用鍵控鎖可解除無謂耦合。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q8, B-Q2, B-Q3

A-Q25: 多機或多進程時如何維持鎖一致性？

• A簡: 需改用跨程序的分散式鎖或外部協調，如 Redis、資料庫、或命名 Mutex。
• A詳: 文章示例的鎖僅在同一進程有效。Web Garden、Web Farm 或容器伸縮會讓每個實例各自上傳。此時需分散式協調（例如 Redis 分散式鎖、資料庫悲觀鎖/唯一索引、雲端鎖服務）來確保同張圖僅由一個實例處理，維持系統一致。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q20, C-Q8, D-Q9

Q&A 類別 B: 技術原理類

B-Q1: FlickrProxy 首次請求與重導流程如何運作？

• A簡: 首次請求檢查快取，若無則上傳並建立快取，完成後重導至 Flickr。
• A詳: 技術原理說明：請求到達後先檢查 CacheInfoFile 是否存在。若不存在，代表從未上傳，需執行上傳並建立快取資訊。關鍵步驟或流程：1) 檢查快取；2) 上鎖（避免並行破壞）；3) 上傳至 Flickr；4) 建立快取資訊；5) 設定回應標頭；6) 重導。核心組件介紹：CacheInfoFile、Flickr API 客戶端、鎖與（可選）信號量。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q1, A-Q2, A-Q20

B-Q2: 初版修正（全域鎖）流程是什麼？

• A簡: 以 lock(this.GetType()) 包住檢查與建立，避免重複但過度序列化。
• A詳: 技術原理說明：所有涉及上傳的請求共用同一鎖，使同時間只允許一個請求進入臨界區。關鍵步驟：1) 取得全域鎖；2) 檢查快取；3) 必要時建立快取與上傳；4) 釋放鎖。核心組件：類型鎖、檢查/建立邏輯。優點是簡單可靠；缺點是對不同照片也互斥，吞吐大幅降低。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q5, A-Q24, B-Q3

B-Q3: 改良版（鍵控鎖）如何設計？

• A簡: 以每張照片專屬鎖保護關鍵段落，不同照片互不阻塞。
• A詳: 技術原理說明：對每張照片建立可重用的鎖物件，將「檢查快取→建立快取」包在 lock(鎖物件) 內。關鍵步驟：1) 取得資源鍵（MD5/路徑）；2) 由字典取回鎖物件；3) 進入臨界區執行檢查與建立；4) 離開臨界區。核心組件：LockHandle、（Concurrent）Dictionary、照片鍵函式。此設計降低鎖競爭，提高併發。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q7, A-Q10, C-Q1

B-Q4: LockHandle 是如何產生的？

• A簡: 以檔案鍵在全域字典中查找或新增一個私有 object 作為鎖。
• A詳: 技術原理說明：先計算檔案鍵（如 MD5 或正規化路徑），再在字典內以該鍵取得現有鎖物件；若無則在臨界區（以字典自身鎖保護）新增。關鍵步驟：1) 計算鍵；2) lock(字典) 檢查/新增；3) 回傳鎖物件。核心組件：鍵函式、鎖物件池、字典同步機制。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q11, B-Q6, C-Q2

B-Q5: 如何從檔案導出唯一鎖物件？

• A簡: 以內容雜湊或正規化路徑做鍵，透過字典映射取得唯一物件。
• A詳: 技術原理說明：唯一鍵確保同一資源對應同一把鎖。雜湊方式抗別名但耗 CPU；路徑正規化省資源但需處理大小寫與捷徑。關鍵步驟：定義鍵函式→建置字典→以 GetOrAdd（或加鎖）取得 object。核心組件：鍵函式、（Concurrent）Dictionary。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q12, A-Q13, C-Q6

B-Q6: 在字典中新增鎖物件時如何保證安全？

• A簡: 必須在互斥下新增，推薦使用 ConcurrentDictionary.GetOrAdd。
• A詳: 技術原理說明：非執行緒安全的 Dictionary 在及時新增時需外部 lock 保護且讀寫在同鎖下；否則可能與他執行緒新增衝突。關鍵步驟：1) 使用 lock(字典) 或採用 ConcurrentDictionary；2) GetOrAdd 原子取回或新建。核心組件：ConcurrentDictionary、同步鎖。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q14, B-Q16, D-Q4

B-Q7: 為何要在 BuildCacheInfoFile 前後上鎖？

• A簡:「檢查→建立」需原子性，避免兩個請求同時判定未建立而重建。
• A詳: 技術原理說明：「檢查是否存在」與「建立」若不在同一臨界區，兩請求都可能看到不存在並各自建立，造成重複上傳與資料競搶。關鍵步驟：用同把鎖包住 Exists 判斷與 Build 操作。核心組件：鎖、檔案系統與 Flickr API 呼叫統一保護邊界。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q3, A-Q23, B-Q8

B-Q8: 上鎖區段應包含哪些最小工作集合？

• A簡: 僅包含「判斷是否需上傳」與「建立副本檔」兩步，其他移出鎖外。
• A詳: 技術原理說明：臨界區應最小化以降低競爭；包含必要原子操作即可。關鍵步驟：1) 進入鎖；2) 檢查快取檔；3) 必要時建立/標記；4) 離開鎖；5) 在鎖外進行非必要互斥的 I/O。核心組件：鎖、快取檔更新、上傳流程切分。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q22, B-Q7, B-Q11

B-Q9: Semaphore 控制並行度的內部機制？

• A簡: 維護計數，WaitOne 減一或等待，Release 加一喚醒等待者。
• A詳: 技術原理說明：計數代表許可證數。當執行緒呼叫 WaitOne 並計數>0 時取得許可並遞減；若為 0 則阻塞等待。Release 增加計數並喚醒等待佇列。關鍵步驟：建立 Semaphore(初始, 最大)→WaitOne→執行→Release。核心組件：系統同步物件、等待佇列。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q15, A-Q16, C-Q3

B-Q10: WaitOne/Release 的生命週期如何管理？

• A簡: 必須成對且包在 try/finally，確保例外時也會釋放。
• A詳: 技術原理說明：WaitOne 取得許可後，若中途拋例外而未 Release，會導致可用計數流失，之後所有請求被永久阻塞。關鍵步驟：try { WaitOne; 執行 } finally { Release; }。核心組件：例外處理、資源釋放慣用語法。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: C-Q4, D-Q3

B-Q11: 如何同時避免重複上傳又限制並行度？

• A簡: 鎖保證單資源一次，上層以信號量限制同時上傳數目。
• A詳: 技術原理說明：鍵控鎖確保同一照片不會重複上傳；Semaphore 則控制跨照片的總並行數。關鍵步驟：1) 先 WaitOne 取得上傳配額；2) 針對目標照片 lock(鎖物件) 做判斷與建立；3) 完成後 Release。核心組件：鎖物件池、Semaphore、上傳器。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q16, A-Q21, C-Q3

B-Q12: ASP.NET 請求併發與 ThreadPool 的關係？

• A簡: 每個請求佔用 ThreadPool 執行緒，阻塞會耗盡執行緒影響併發。
• A詳: 技術原理說明：ASP.NET 以 ThreadPool 供應請求處理執行緒。長時間同步 I/O 或等待會佔住執行緒，減少可處理請求的名額。關鍵步驟：使用非同步 I/O、減少鎖持有時間、必要時調整 ThreadPool 設定。核心組件：ThreadPool、非同步程式模型。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q19, B-Q19, D-Q2

B-Q13: 可能的死鎖情境與避免機制？

• A簡: 交錯鎖順序、重入與遺漏釋放會死鎖；採固定順序與 finally。
• A詳: 技術原理說明：兩把以上鎖若取得順序不一致易造成環形等待；重入風險與跨層鎖交錯亦危險。關鍵步驟：統一鎖取得順序；縮短臨界區；Release/Exit 放於 finally；避免公開物件鎖。核心組件：鎖階層化策略、例外安全。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q10, D-Q5

B-Q14: 以字串作鎖的風險機制（Interning）？

• A簡: 字串內插可能讓不同程式片段共享同物件，導致意外競爭或死鎖。
• A詳: 技術原理說明：CLR 對常量字串進行 Intern，同值字串可能指向同一實例。若對外可見字串作鎖，其他元件也可能鎖到同一物件。關鍵步驟：避免鎖字串與公共物件；改用私有 readonly object 或鍵控鎖。核心組件：字串內插池、鎖物件封裝。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q9, B-Q16

B-Q15: 字典競態與記憶體管理要點？

• A簡: 寫入需同步；長期運行需控制鍵數量與釋放策略。
• A詳: 技術原理說明：Dictionary 非執行緒安全，並發寫入會造成例外或資料損壞。採 ConcurrentDictionary 或外部鎖。關鍵步驟：原子 GetOrAdd；可搭配 WeakReference 或清理機制移除冷鍵。核心組件：並發容器、GC 互動、快取管理。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q14, C-Q2, D-Q4

B-Q16: 使用 ConcurrentDictionary.GetOrAdd 的架構？

• A簡: 以鍵原子取回或建立鎖物件，免去外部鎖，簡化並發管理。
• A詳: 技術原理說明：GetOrAdd 在內部保證單鍵操作的原子性，避免重複建立與競態。關鍵步驟：定義鍵→Locks.GetOrAdd(key, _ => new object())。核心組件：ConcurrentDictionary、鍵函式。此法也可換成 Lazy
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q2, B-Q17

B-Q17: Lazy

• A簡: 延遲建立且具執行緒安全，保證同一鍵只建一次物件。
• A詳: 技術原理說明：Lazy 可設定 LazyThreadSafetyMode.ExecutionAndPublication，確保在並發情境下值只被建立一次並公布給所有讀者。關鍵步驟：GetOrAdd(key, _ => new Lazy
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q16, C-Q2

B-Q18: 例外時如何確保釋放信號量？

• A簡: 以 try/finally 包住 WaitOne 與 Release，任何路徑都會釋放。
• A詳: 技術原理說明：釋放遺漏會造成可用名額流失與長期阻塞。關鍵步驟：try { semaphore.WaitOne(); 執行工作 } finally { semaphore.Release(); }；若有多層呼叫，務必在最靠近 Wait 的區塊保證釋放。核心組件：例外安全、資源釋放慣例。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q10, C-Q4, D-Q3

B-Q19: SemaphoreSlim 與非同步流程的設計？

• A簡: 以 WaitAsync/Release 搭配 async/await，避免阻塞 ThreadPool。
• A詳: 技術原理說明：SemaphoreSlim 支援非同步等待，讓等待期間不綁定執行緒。關鍵步驟：await semaphore.WaitAsync(); try { await 上傳Async; } finally { semaphore.Release(); }。核心組件：SemaphoreSlim、async/await、非同步 I/O。能顯著提升 ASP.NET 可伸縮性。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q19, C-Q5

B-Q20: 跨程序/跨機鎖的技術選項？

• A簡: 可用 Redis 分散式鎖、資料庫鎖/唯一鍵、雲鎖服務或命名 Mutex。
• A詳: 技術原理說明：單機鎖僅限進程內。分散式鎖透過外部一致性存放（Redis set NX + TTL、DB 悲觀鎖或唯一鍵插入、雲端協調）維持跨實例互斥。關鍵步驟：嘗試取得鎖→執行→釋放/過期。核心組件：外部儲存、租約 TTL、心跳續約。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q25, C-Q8, D-Q9

B-Q21: 檔案雜湊計算的成本與快取？

• A簡: 雜湊耗 CPU；可快取結果或改用路徑鍵，視場景取捨。
• A詳: 技術原理說明：MD5 計算隨檔案大小線性成長，對大圖批量會顯著佔用 CPU。關鍵步驟：將雜湊結果緩存（MemoryCache）並設定過期；或改用正規化路徑鍵。核心組件：雜湊演算法、快取、統計監控以評估成本。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q12, C-Q6, D-Q7

B-Q22: 單頁大量圖片時的併發行為與控制？

• A簡: 多張首請求同時上傳，應以 Semaphore 節流並保留每張鎖互斥。
• A詳: 技術原理說明：瀏覽器會並行發出多個請求。鍵控鎖避免同圖重複上傳；Semaphore 控制同時上傳數（如 2 個），平衡外部 API 壓力。關鍵步驟：先 Wait，再 per-file lock，完成後 Release。核心組件：鍵控鎖、信號量、上傳器。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q17, B-Q11, C-Q3

B-Q23: CacheInfoFile 的角色與一致性策略？

• A簡: 標記與描述上傳完成狀態；需確保建立過程原子與可恢復。
• A詳: 技術原理說明：快取資訊檔用來判斷是否已上傳與重導資料。關鍵步驟：臨界區內以臨時檔寫入後原子性 rename 取代，避免中途崩潰遺留半成品；必要時加入冪等標記。核心組件：檔案系統原子操作、冪等寫入與校驗。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q7, D-Q6

B-Q24: 回應標頭設計與觀測性如何實作？

• A簡: 自訂標頭與日誌紀錄上傳事件，輔以計量與追蹤提升可觀測性。
• A詳: 技術原理說明：於首次上傳回應加入 X-FlickrProxy: Upload，並在伺服器端記錄事件、耗時、鎖等待與信號量等待。關鍵步驟：寫入標頭→結合結構化日誌與指標→建立儀表板。核心組件：HTTP 標頭、日誌、度量（如 Prometheus/Application Insights）。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q20, C-Q9, D-Q10

B-Q25: 鎖粒度、競爭、吞吐與延遲的取捨？

• A簡: 細粒度提升吞吐但複雜；粗粒度簡單但延遲高，需依負載調整。
• A詳: 技術原理說明：鎖太細增加設計難度與管理成本；鎖太粗造成等待與低效。關鍵步驟：觀測實際競爭、延遲分佈，調整臨界區大小與並行上限；必要時引入分散式鎖或非同步。核心組件：性能剖析、容量規劃、同步策略。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q6, B-Q8, B-Q22

Q&A 類別 C: 實作應用類

C-Q1: 如何以 Dictionary 實作每張照片的鍵控鎖？

• A簡: 以檔案鍵映射到私有鎖物件，lock 該物件保護檢查與建立流程。
• A詳: 具體實作步驟：1) 設計鍵函式（MD5/路徑）；2) 於全域容器維護 key→object；3) 取得鎖物件後 lock 包住 Exists/Build。關鍵程式碼片段或設定:

  static readonly object dictLock = new object();
  static readonly Dictionary<string, object> Locks = new();
  object GetLock(string key){
  lock (dictLock){
    if(!Locks.TryGetValue(key, out var o)) Locks[key]=o=new object();
    return o;
  }
  }
  lock(GetLock(key)){
  if(!File.Exists(CacheInfo)) { BuildCacheInfo(context); }
  }
  

  注意事項與最佳實踐：讀寫皆須在同一 dictLock 下；或改用 ConcurrentDictionary 簡化。

• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3, B-Q6, C-Q2

C-Q2: 如何以 ConcurrentDictionary 簡化 LockHandle？

• A簡: 用 GetOrAdd 原子取得鎖，避免外部鎖，程式更簡潔安全。
• A詳: 具體實作步驟：1) 建立 ConcurrentDictionary<string, object>，指定字串比較器；2) 以 GetOrAdd 取得鎖；3) lock 該鎖執行臨界區。關鍵程式碼片段或設定:

  static readonly ConcurrentDictionary<string, object> Locks =
  new(StringComparer.OrdinalIgnoreCase);
  var handle = Locks.GetOrAdd(key, _ => new object());
  lock(handle){
  if(!File.Exists(CacheInfo)) { BuildCacheInfo(context); }
  }
  

  注意事項與最佳實踐：確保 key 正規化；避免以公開物件當鎖。

• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q16, B-Q17

C-Q3: 如何限制同時上傳不超過 2 個（Semaphore）？

• A簡: 建立 Semaphore(2,2)，於上傳前 WaitOne，完成後 Release。
• A詳: 具體實作步驟：1) 定義全域信號量；2) 上傳前取得許可；3) 上傳後釋放。關鍵程式碼片段或設定:

  static readonly Semaphore UploadGate = new(2, 2);
  UploadGate.WaitOne();
  try{
  photoId = flickr.UploadPicture(filePath);
  } finally {
  UploadGate.Release();
  }
  

  注意事項與最佳實踐：務必以 try/finally 確保釋放；配合 per-file 鎖避免重複上傳。

• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q9, B-Q11, B-Q10

C-Q4: 如何用 try/finally 保證 Release 不遺漏？

• A簡: 將 WaitOne 放在 try 前，Release 放在 finally，避免例外導致資源流失。
• A詳: 具體實作步驟：1) WaitOne；2) try{執行上傳}finally{Release}；3) 記錄例外。關鍵程式碼片段或設定:

  UploadGate.WaitOne();
  try { DoUpload(); }
  catch(Exception ex){ Log(ex); throw; }
  finally { UploadGate.Release(); }
  

  注意事項與最佳實踐：同理於 lock 可用 using Monitor.Enter/Exit；將最昂貴/易例外區塊納入保護與釋放。

• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q10, B-Q18

C-Q5: 如何用 SemaphoreSlim 與 async/await 非阻塞上傳？

• A簡: 以 WaitAsync/Release 包裝非同步上傳，減少 ThreadPool 阻塞。
• A詳: 具體實作步驟：1) 定義 SemaphoreSlim(2,2)；2) await WaitAsync；3) try{await 上傳} finally Release。關鍵程式碼片段或設定:

  static readonly SemaphoreSlim Gate = new(2, 2);
  await Gate.WaitAsync();
  try{
  await flickr.UploadPictureAsync(filePath);
  } finally {
  Gate.Release();
  }
  

  注意事項與最佳實踐：配合 ASP.NET async 處理管線；避免同步阻塞呼叫。

• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q19, A-Q19

C-Q6: 如何避免 MD5 計算，改用正規化路徑鍵？

• A簡: 使用完整路徑與大小寫不敏感比較，省 CPU 並保鍵一緻。
• A詳: 具體實作步驟：1) var key = Path.GetFullPath(path); 2) Locks 使用 StringComparer.OrdinalIgnoreCase；3) 以 key 做 GetOrAdd。關鍵程式碼片段或設定:

  var key = Path.GetFullPath(filePath);
  var handle = Locks.GetOrAdd(key, _ => new object());
  lock(handle){ ... }
  

  注意事項與最佳實踐：處理連結/捷徑；內容更新時同步快取失效策略。

• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q13, B-Q21

C-Q7: 如何在 ASP.NET Handler/Middleware 插入此邏輯？

• A簡: 於處理管線中攔截圖檔請求，實作檢查→鎖→上傳→回應流程。
• A詳: 具體實作步驟：1) 實作 IHttpHandler 或 .NET Core Middleware；2) 解析目標檔案；3) 取得 per-file 鎖；4) 檢查/建立快取；5) 控制上傳並設標頭；6) 重導。關鍵程式碼片段或設定: 在 Invoke/ProcessRequest 中套用 C-Q2/C-Q3 片段。注意事項與最佳實踐：非同步優先；記錄指標與錯誤。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q1, B-Q12, C-Q5

C-Q8: 多台 Web Server 下如何用 Redis 實作分散式鎖？

• A簡: 以 SET NX PX 取得含 TTL 的租約，成功者執行，完成後 DEL 釋放。
• A詳: 具體實作步驟：1) 建立鎖鍵（照片鍵）；2) SET key value NX PX=TTL；3) 成功才上傳；4) 以 Lua 腳本檢查 value 再刪除釋放。關鍵程式碼片段或設定:

  SET lock:photoKey requestId NX PX 30000
  if OK -> do upload
  EVAL "if redis.call('get',KEYS[1])==ARGV[1] then return redis.call('del',KEYS[1]) end" 1 lock:photoKey requestId
  

  注意事項與最佳實踐：設定合理 TTL、續約與容錯；可用 RedLock 套件。

• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q25, B-Q20

C-Q9: 如何加入 X-FlickrProxy 標頭與日誌追蹤？

• A簡: 首次上傳時加上 X-FlickrProxy: Upload，並寫入結構化日誌與計量。
• A詳: 具體實作步驟：1) 判斷是首次上傳；2) Response.AddHeader(“X-FlickrProxy”,”Upload”); 3) 記錄上傳耗時、鎖等待時間、錯誤。關鍵程式碼片段或設定:

  if(firstUpload){
  context.Response.AddHeader("X-FlickrProxy","Upload");
  logger.LogInformation("Upload {Key} in {ms}ms, wait {w}ms", key, sw.ElapsedMs, waitMs);
  }
  

  注意事項與最佳實踐：避免多次加入重複標頭；隱私與安全審視。

• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q20, B-Q24

C-Q10: 如何撰寫併發測試避免重複上傳？

• A簡: 以多工作同時打同一資源，驗證只觸發一次上傳與正確重導。
• A詳: 具體實作步驟：1) 建立能記錄上傳次數的假 Flickr 客戶端；2) 並行觸發 10 次請求同圖；3) 斷言上傳次數=1；4) 檢查標頭與回應。關鍵程式碼片段或設定:

  await Task.WhenAll(Enumerable.Range(0,10).Select(_=> RequestSamePhoto()));
  Assert.Equal(1, fakeUploader.UploadCount);
  

  注意事項與最佳實踐：再測多圖多請求情境；測超時與錯誤恢復。

• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q21, B-Q22

Q&A 類別 D: 問題解決類

D-Q1: 出現同一張照片重複上傳，怎麼辦？

• A簡: 檢查是否缺少 per-file 鍵控鎖，確保「檢查→建立」在同一臨界區。
• A詳: 問題症狀描述：相同圖片短時間被上傳兩次以上。可能原因分析：未上鎖、鎖粒度過大/過小、臨界區未涵蓋檢查與建立。解決步驟：實作鍵控鎖；將 Exists 與 Build 同鎖包覆；加入觀測日志。預防措施：撰寫併發測試與壓力測試，持續監控上傳次數。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, B-Q7, C-Q1

D-Q2: 大量請求時效能驟降怎麼辦？

• A簡: 檢查是否使用全域鎖或臨界區過大，並以 Semaphore 節流上傳。
• A詳: 問題症狀描述：吞吐下降、延遲上升。可能原因分析：全域鎖序列化不同資源；臨界區包含昂貴 I/O；無節流導致資源爭用。解決步驟：改鍵控鎖；縮小臨界區；引入 Semaphore 限制並行上傳。預防措施：壓力測試與指標監控調優。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q5, B-Q25, C-Q3

D-Q3: 忘記呼叫 Semaphore.Release 導致阻塞？

• A簡: 會耗盡許可導致永久等待；以 try/finally 包裝確保釋放。
• A詳: 問題症狀描述：新請求長期掛起。可能原因分析：例外中斷未釋放；多次 Wait 少次 Release。解決步驟：將 Release 放於 finally；對不平衡呼叫進行代碼審查。預防措施：單元測試注入故障；度量剩餘許可與等待時間警報。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q10, B-Q18, C-Q4

D-Q4: 字典拋出「Collection was modified」例外如何處理？

• A簡: 並發寫入造成；改用 ConcurrentDictionary 或以同一鎖保護讀寫。
• A詳: 問題症狀描述：高併發下偶發例外。可能原因分析：Dictionary 在另一執行緒寫入時，本執行緒讀取。解決步驟：改用 ConcurrentDictionary.GetOrAdd；或統一以同一鎖包住讀/寫。預防措施：避免在鎖外讀取；加入壓力測試驗證。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, B-Q16, C-Q2

D-Q5: 發生死鎖或請求卡住無回應怎麼診斷？

• A簡: 檢查鎖順序、嵌套鎖與外部可見鎖，並導入超時與轉儲分析。
• A詳: 問題症狀描述：Threads 長時間等待。可能原因分析：鎖順序不一致、跨層鎖相互等待、鎖住公共物件。解決步驟：統一鎖階層順序；縮短臨界區；避免鎖字串/Type；加入鎖等待超時與日誌。預防措施：代碼規範與審查、工具分析 Dump。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q13, B-Q14

D-Q6: 上傳期間中斷導致 CacheInfoFile 不一致？

• A簡: 可能寫入半成品；採用臨時檔寫入與原子替換策略。
• A詳: 問題症狀描述：快取檔存在但內容不完整。可能原因分析：寫入過程崩潰或競態。解決步驟：臨界區內先寫 .tmp，完成後 File.Replace/Move 覆蓋；驗證校驗碼。預防措施：冪等處理、寫入後校驗與回滾機制。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q23, C-Q1

D-Q7: 計算 MD5 造成 CPU 飆高怎麼辦？

• A簡: 改用正規化路徑鍵或快取雜湊結果，並平衡負載。
• A詳: 問題症狀描述：CPU 高、RT 提升。可能原因分析：大檔批次 MD5 計算。解決步驟：路徑鍵替代 MD5；或將雜湊結果快取，設定滑動過期；下調並行上傳。預防措施：定期剖析與指標警示；容量規劃。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q21, C-Q6

D-Q8: X-FlickrProxy 標頭未出現如何排查？

• A簡: 確認是否真的首次上傳、是否於正確分支加標頭、或被覆蓋。
• A詳: 問題症狀描述：預期首次上傳卻沒標頭。可能原因分析：已有快取、加標頭位置在重導後、或中間件移除。解決步驟：在建立快取成功後立即加標頭；檢查重導/壓縮中介；加入日誌。預防措施：端對端測試與回應檢查。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q20, C-Q9

D-Q9: 多機部署仍然重複上傳怎麼辦？

• A簡: 單機鎖無效，需導入分散式鎖或唯一鍵寫入策略。
• A詳: 問題症狀描述：多台 Web 同時上傳同照片。可能原因分析：鎖僅進程內有效。解決步驟：採 Redis 分散式鎖、DB 唯一鍵去重、或雲協調服務；於上傳紀錄表加唯一鍵避免重複。預防措施：在擴展前納入設計，壓測與混沌測試。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q25, B-Q20, C-Q8

D-Q10: 首次請求延遲過久，如何診斷與優化？

• A簡: 分解等待：鎖等待、信號量、上傳 I/O，並據以縮小臨界區與改非同步。
• A詳: 問題症狀描述：TTFB 長、用戶體感慢。可能原因分析：鎖競爭、上傳併發過多、同步 I/O。解決步驟：記錄鎖/信號量等待時間；上傳改 async；降低並行至合理值；快取預熱。預防措施：A/B 度量與容量規劃、觀測性儀表板。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q24, B-Q25, C-Q5

學習路徑索引

• 初學者：建議先學習哪 15 題
  • A-Q1: 什麼是 FlickrProxy 專案？
  • A-Q2: 為何會發生重複上傳到 Flickr 的問題？
  • A-Q3: 什麼是臨界區（Critical Section）？
  • A-Q4: 在 ASP.NET 中 lock 是什麼？為何使用？
  • A-Q5: lock 範圍過大會有什麼影響？
  • A-Q6: 什麼是鎖的粒度（Lock Granularity）？
  • A-Q7: 為何要對同一張照片的請求才上鎖？
  • A-Q8: lock(this.GetType()) 與 lock(專屬物件) 的差異？
  • A-Q15: 什麼是信號量（Semaphore）？
  • A-Q16: lock 與 Semaphore 有何差異？
  • B-Q1: FlickrProxy 首次請求與重導流程如何運作？
  • B-Q2: 初版修正（全域鎖）流程是什麼？
  • B-Q7: 為何要在 BuildCacheInfoFile 前後上鎖？
  • C-Q3: 如何限制同時上傳不超過 2 個（Semaphore）？
  • C-Q4: 如何用 try/finally 保證 Release 不遺漏？
• 中級者：建議學習哪 20 題
  • A-Q10: 什麼是鍵控鎖（Keyed Locking）？
  • A-Q11: LockHandle 的核心角色是什麼？
  • A-Q12: 為何要用 MD5 作為檔案識別鍵？
  • A-Q13: 使用正規化路徑取代 MD5 的可行性？
  • A-Q14: Dictionary 作為鎖物件容器的優缺點？
  • A-Q17: 為何需要限制同時上傳數量？
  • A-Q19: 為何在 ASP.NET 中避免長時間阻塞？
  • A-Q20: X-FlickrProxy 回應標頭的用途？
  • A-Q21: 什麼是請求合併（Single-flight）？
  • A-Q22: 為何「只鎖必要區段」很重要？
  • B-Q3: 改良版（鍵控鎖）如何設計？
  • B-Q6: 在字典中新增鎖物件時如何保證安全？
  • B-Q8: 上鎖區段應包含哪些最小工作集合？
  • B-Q9: Semaphore 控制並行度的內部機制？
  • B-Q11: 如何同時避免重複上傳又限制並行度？
  • B-Q12: ASP.NET 請求併發與 ThreadPool 的關係？
  • B-Q21: 檔案雜湊計算的成本與快取？
  • B-Q22: 單頁大量圖片時的併發行為與控制？
  • C-Q2: 如何以 ConcurrentDictionary 簡化 LockHandle？
  • C-Q6: 如何避免 MD5 計算，改用正規化路徑鍵？
• 高級者：建議關注哪 15 題
  • A-Q25: 多機或多進程時如何維持鎖一致性？
  • B-Q13: 可能的死鎖情境與避免機制？
  • B-Q14: 以字串作鎖的風險機制（Interning）？
  • B-Q15: 字典競態與記憶體管理要點？
  • B-Q16: 使用 ConcurrentDictionary.GetOrAdd 的架構？
  • B-Q17: Lazy
  • B-Q19: SemaphoreSlim 與非同步流程的設計？
  • B-Q20: 跨程序/跨機鎖的技術選項？
  • B-Q23: CacheInfoFile 的角色與一致性策略？
  • B-Q24: 回應標頭設計與觀測性如何實作？
  • B-Q25: 鎖粒度、競爭、吞吐與延遲的取捨？
  • C-Q5: 如何用 SemaphoreSlim 與 async/await 非阻塞上傳？
  • C-Q7: 如何在 ASP.NET Handler/Middleware 插入此邏輯？
  • C-Q8: 多台 Web Server 下如何用 Redis 實作分散式鎖？
  • D-Q9: 多機部署仍然重複上傳怎麼辦？