diff --git "a/chapter6/6.8 final\345\205\263\351\224\256\345\255\227.md" "b/chapter6/6.8 final\345\205\263\351\224\256\345\255\227.md"
index 6ed5020..5663466 100644
--- "a/chapter6/6.8 final\345\205\263\351\224\256\345\255\227.md"	
+++ "b/chapter6/6.8 final\345\205\263\351\224\256\345\255\227.md"	
@@ -206,4 +206,4 @@ public class Jurassic {
 
 标准Java库是阐述这一观点的最好例子。其中特别常用的一个类是Vector。如果我们考虑代码的执行效率，就会发现只有不把任何方法设为final，才能使其发挥更大的作用。我们很容易就会想到自己应继承和覆盖如此有用的一个类，但它的设计者却否定了我们的想法。但我们至少可以用两个理由来反驳他们。首先，Stack（堆栈）是从Vector继承来的，亦即Stack“是”一个Vector，这种说法是不确切的。其次，对于Vector许多重要的方法，如addElement()以及elementAt()等，它们都变成了synchronized（同步的）。正如在第14章要讲到的那样，这会造成显著的性能开销，可能会把final提供的性能改善抵销得一干二净。因此，程序员不得不猜测到底应该在哪里进行优化。在标准库里居然采用了如此笨拙的设计，真不敢想象会在程序员里引发什么样的情绪。
 
-另一个值得注意的是Hashtable（散列表），它是另一个重要的标准类。该类没有采用任何final方法。正如我们在本书其他地方提到的那样，显然一些类的设计人员与其他设计人员有着全然不同的素质（注意比较Hashtable极短的方法名与Vecor的方法名）。对类库的用户来说，这显然是不应该如此轻易就能看出的。一个产品的设计变得不一致后，会加大用户的工作量。这也从另一个侧面强调了代码设计与检查时需要很强的责任心。
+另一个值得注意的是Hashtable（散列表），它是另一个重要的标准类。该类没有采用任何final方法。正如我们在本书其他地方提到的那样，显然一些类的设计人员与其他设计人员有着全然不同的素质（注意比较Hashtable极短的方法名与Vector的方法名）。对类库的用户来说，这显然是不应该如此轻易就能看出的。一个产品的设计变得不一致后，会加大用户的工作量。这也从另一个侧面强调了代码设计与检查时需要很强的责任心。