Java final 方法使用誡：性能優化與擴展性封殺的雙刃劍

final 方法雙重動機

1. 鎖定行為：防止衍生類覆寫改變語義。
2. 性能優化：編譯器可內聯調用，消除方法調用開銷。

濫用 final 的代價：Vector 教訓

標準庫 Vector 所有方法均非 final，設計者刻意保留擴展性。但：

• Stack 繼承 Vector 違反「是一個」原則（棧不是矢量）。
2. 關鍵方法 addElement()、elementAt() 被標記 synchronized，同步開銷遠超 final 內聯收益。

結果：final 帶來的微小性能增益被 synchronized 抵消，卻封殺了合理繼承擴展。設計失衡。

Hashtable 的對比

Hashtable 無 final 方法，方法名極短（put/get），設計質量顯著高於 Vector。標準庫內部設計風格不一，增加使用者認知負擔。

最佳實踐

只有以下情況才考慮 final 方法：
• 方法極小（getter/工具方法）
• 極高頻調用（熱點路徑）
• 業務語義確定不允許覆寫（如模板方法模式中的骨架步驟）
常規類默認不加 final，保留擴展可能。