java 同步接口_java – 对接口和同步集合进行编程

这个问题与

Java集合有关 – 特别是Hashtable和Vector – 但也可能适用于其他地方.

我在很多地方都读到了编程接口的好处,我同意100%.例如,在不考虑底层实现的情况下编程到List接口的能力对解耦和测试目的肯定是有帮助的.考虑到内部存储结构,随机访问时间等方面的差异,我可以看到ArrayList和LinkedList如何适用于不同的环境.然而,这两个实现可以在同一个接口下使用…是很棒的.

我似乎无法放置的是某些同步实现(特别是Hashtable和Vector)如何适应这些接口.对我来说,他们似乎不适合这个模型.大多数底层数据结构实现似乎在数据存储方式(LinkedList,Array,排序树等)方面有所不同,而同步则处理可以访问数据的条件(锁定条件).让我们看一个方法返回Map集合的示例:

public Map getSomeData();

让我们假设应用程序完全不关心并发性.在这种情况下,我们对该方法通过接口返回的任何实现进行操作……每个人都很高兴.世界是稳定的.

但是,如果应用程序现在需要关注并发性前端怎么办?我们现在无法在不考虑底层实现的情况下运行 – Hashtable会很好,但其他实现必须满足.让我们考虑3个场景:

1)在使用集合添加/删除时,使用同步块等强制执行同步.但是,如果同步实现(Hashtable)被返回,这不会是过度杀伤吗?

2)更改方法签名以返回Hashtable.然而,这将我们与Hashtable实现紧密联系在一起,因此,编程到界面的优势被抛到了窗外.

3)利用并发包并更改方法签名以返回ConcurrentMap接口的实现.对我来说,这似乎是前进的方向.

从本质上讲,似乎某些同步实现在集合框架中有点不合适,因为当对接口进行编程时,同步问题几乎迫使人们考虑底层实现.

我完全忽略了这一点吗?

谢谢.

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值