浅谈一下java API设法的一个错误带来的后果引以为戒

java从出台以来有十二年的历史了，我们从未知到现在被广大程序员所接受 正是说明了它有其存在与发展的空间
但是人无完人 java在设计上也有自身的缺点，举个例子：从API里可以看到java.util.Stack类，stack 的特点是后进先出 且不能查找 array的特点是易于查找但是增删比较难
这个一般的程序员都很清楚 这个类是java.util.Vector的子类，Vector底层实现是用array且线程安全，这就与statck本身的特点不符合，再者由于是继承，stack就会将父类的所有方法都继承过来
如：add(int index,E element)这与stack是根本就不能实现的 但是SUN公司对于这个错误是没办法挽回了 以至于这个错误就一直错了十多年 最后SUN公司给出的解释就是不要轻易用这个类
从这件小事上来说明 一个设计者小小的失误对代码或者一个应用会起到为意想不到的结果 所以我们要努力再努力去完善自己

不知道是不是作者偷懒，哈哈，继承Vector实在是匪夷所思。无依无靠实现个stack也不是什么难事吧。

小玩子 写道：

的确 我猜测可能是因为STL里一般用dequeue adapt stack, 但是JAVA没有dequeue 所以选择了vector
可以选择用LinkedList实现 也可以封装JDK的stack

或者用Linkedlist也可以嘛
就是不知道为啥要选用vector

Stack 是从1.0就有了, 那时候还不是 Collections Framework, java.util.* 的设计也就没有那么成体系, 看看 Properties, Hashtable 也差不多.

Java 在 1.0 的时代还挣扎在生存斗争里, 主要精力还是在 安全, 网络, 跨平台 等等那些亮点上, 细节上感觉没有顾得上精雕细琢. 到了1.1好像底气才比较足起来, 做了很多重大改进.

其实像 StringBuffer 也是类似, 程序里 String s = "Hello, " + "World" 这样的语句是编译为 String s = new StringBuffer().append("Hello,").append("World").toString(); 的, 这种用法用户代码根本得不到那个StringBuffer的引用, 也就不可能在多个线程间共享, 所以也就根本不可能出现并发访问, 用不着同步的.

但是StringBuffer从头到尾都是同步实现的, 当然也是考虑给不注意同步问题的程序员预先买单, 而且牺牲的只是大约30%的性能, Java一开始的时候自己已经慢得够呛了, 这点性能损失虽然没有必要, 但是很不明显.

另外一个可能的部分原因是Java的同步机制太有创意了, 最初大家都很兴奋, 喜欢把它用在各种看起来需要的地方.

不过现在Java的性能问题已经是本质性的改善了, 也确立了自己的地位, 类似的历史问题也到了回过头去追求完美的时候了. 所以从5.0开始, 引入了 StringBuilder, 不需要同步的时候就用它, 而接口和实现逻辑与StringBuffer完全相同, 只是简单去掉了一些synchronized关键字.

好像1.6StringBuffer还有一个类似的类 StringBuilder 速度要比StringBuffer快 但是线程不安全

晕 应该是1.5 咋打错了呢

集合操作线程同步意义不大，只能保证操作的原子性，不能保证数据的完整性。StringBuffer得不偿失。

集合需要同步的情况还是比较常见，不过也没必要在实现类里面实现，后来jdk4的Collections工具类的一些同步包装方法就比较漂亮。

很难想象StringBuffer需要同步的情景。

用Linkedlist实现stack完全没有道理。
stack只能从一头增删数据。如果不考虑shink和海量数据的话，vector还是很适合的。

linkedlist辅助空间极大，而且添加删除也比较慢。并不适合用来实装stack.

另外C++的STL的STACK的内部存储结构是可选的。并不局限于deque。