不该用 Stack 类，因其继承过时的 Vector、同步开销大、破坏封装（如 get(i) 可随意访问中间元素）；应改用 ArrayDeque 实现 Deque 接口，性能更好、API 更纯粹。
Java 的类不推荐用于新代码，它继承自过时的，线程安全但性能差，且设计违反封装原则（比如能用随意访问中间元素）。
为什么不该用
类
它本质是带额外方法的
，所有操作都加了
，即使单线程也白耗开销；
和
底层调用的是
和
，语义冗余；更严重的是，它公开了
、
等破坏栈抽象的方法。
实际项目中，JDK 官方文档明确建议用
实现栈，比如
—— 它更快、更轻量、API 更纯粹。
用
替代
的正确写法
把
换成：
立即学习
“
Java免费学习笔记（深入）
”；
对应操作直接映射：
→ 仍可用（
实现了
）
→ 返回栈顶并移除，行为一致
→ 查看栈顶不移除，和
一样
→ 判空，无差异
注意：
不支持
元素，而
可以——如果业务逻辑真依赖存
，说明栈设计本身就有问题，该重构。
Eclipse导入Android或其他的JAVA项目的正确方法 WORD版
本文档主要讲述的是Eclipse导入Android或其他的JAVA项目的正确方法；希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
下载
遇到
怎么办
无论是
还是
，在空时都会抛
。这不是 bug，是契约行为。
安全做法永远是先判空再操作：
别依赖
来控制流程——这会掩盖真实异常，且性能差。有些旧代码用
判断，对
没问题，但
对某些
实现（如并发场景下的
）可能不精确，所以坚持用
。
如果必须兼容老
接口怎么办
比如对接遗留系统或第三方库强制要求
类型参数。这时不要继承
或包装它，而是用适配器模式最小化侵入：
关键点：
重写所有方法，确保内部只走
保留
仅为了满足
接口签名，实际已无同步必要
绝不在外部暴露
或调用
的
方法
真正难的不是语法，是意识到：栈不是“能后进先出就行”，而是“接口干净、行为可预测、扩展无隐患”。用错容器，后面 debug 时看到
返回 5 但
却抛异常，就只能翻源码了。
StackVectorget(i)StackVectorsynchronizedpush()pop()addElement()removeElementAt(size()-1)elementAt()setSize()DequeArrayDequeArrayDequeStackStack stack = new Stack<>(); Deque stack = new ArrayDeque<>(); stack.push("a")ArrayDequepush()stack.pop()stack.peek()Stackstack.isEmpty()ArrayDequenullStacknullEmptyStackExceptionStack.pop()ArrayDeque.pop()EmptyStackExceptionif (!stack.isEmpty()) {
String top = stack.pop();
}try-catchstack.size() > 0ArrayDequesize()DequeConcurrentLinkedDequeisEmpty()StackStackStackpublic class DequeStack extends Stack {
private final Deque delegate = new ArrayDeque<>();
@Override
public E push(E item) {
delegate.push(item);
return item;
}
@Override
public synchronized E pop() {
if (delegate.isEmpty()) throw new EmptyStackException();
return delegate.pop();
}
// 其他方法同理，只转发到 delegate，屏蔽 Vector 特性
} ArrayDequesynchronizedStackdelegatesuperVectorStack.size()peek()