将Collections.unmodifiable *传递给已经用Collections.unmodifiable *包装的实例,效率低下吗?

将Collections.unmodifiable *传递给已经用Collections.unmodifiable *包装的实例,效率低下吗?,第1张

将Collections.unmodifiable *传递给已经用Collections.unmodifiable *包装的实例,效率低下吗?

查看所有反馈后,我得出的结论是,无论我做什么,解决方案都将是某种形式的污泥(有轻微的气味)。我认为这是由于这样的事实,即Collections
API的产生不可修改实例的部分没有提供避免嵌套不可修改实例的功能,也没有为客户端提供一种“公共”方式来正确避免嵌套。

并且由于考虑到多个类加载器以及通过RMI进行序列化的考虑,我真正喜欢的一个解决方案(Jorn
Horstmann的类参考比较)存在问题。但是,当我采用他的方法并将其与对类名方法的修改(由Eugene
Kuleshov推荐)相结合时,我认为我将尽可能接近找到一种对我的多线程有帮助的解决方案分布式处理环境。它有点像这样:

public class MyCollections {    private static final String UNMODIFIABLE_MAP_CLASS_NAME =        Collections.unmodifiableMap(new HashMap()).getClass().getName();    public static <K, V> Map<K, V> unmodifiableMap(Map<K, V> map) {        return map.getClass().getName().equals(UNMODIFIABLE_MAP_CLASS_NAME)      ? map      : Collections.unmodifiableMap(map);    }}

假设 所有事情都在同一个ClassLoader上下文中发生 并且
类名的字符串已正确插入,那么这仍然具有引用比较的所有优点。并且在礼貌地保持封装的同时做到了这一点(避免我的代码直接引用类名)。但是,如果这两个假设不成立,则评估将退回到标准字符串比较,前提是假设类名在库的不同版本之间没有变化(这似乎可能性很小)。

这种方法有什么我遗忘或遗漏的吗?

再次感谢大家,您的反馈意见。我真的很感激。



欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/zaji/5507107.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-12-13
下一篇 2022-12-13

发表评论

登录后才能评论

评论列表(0条)

保存