java - 保持数据结构 View 一致

Question

我有一个订单的Map，可以由许多不同的线程访问。我想控制访问，所以考虑以下简单的数据结构+包装器。

public interface OrderContainer {
    boolean contains(String orderId);
    Order get(String orderId);
    Order register(Order value);
    Order remove(String orderId);
    Collection<Order> getOrders();
}

public class SimpleOrderContainer implements OrderContainer {
    private Map<String, Order> orders = new ConcurrentHashMap<>();
    private Collection<Order> ordersView = Collections.unmodifiableCollection(orders.values());

    @Override
    public boolean contains(String orderId) {
        return orders.containsKey(orderId);
    }

    @Override
    public Order get(String orderId) {
        return orders.get(orderId);
    }

    @Override
    public Order register(Order value) {
        return orders.put(value.getId(), value);
    }

    @Override
    public Order remove(String orderId) {
        return orders.remove(orderId);
    }
    
    @Override
    public Collection<Order> getOrders() {
        return ordersView;
    }
}

非常简单。现在，Order 有另一个方法，getType。我要decorate我的类能够按类型访问订单，但我不想每次调用此方法时都必须迭代整个 map ；我想保留包含此信息的 View 。

问题:

1. 以线程安全的方式保持两个 View 彼此一致
2. 我尝试执行#1 时可能会过度同步，从而影响性能
3. 我无法确保没有人保留对原始 OrderContainer 的引用，这会导致我的 typeView 不同步。

这是我第一次尝试装饰类。这种尝试几乎肯定会过度同步:

public class TypeOrderContainer implements OrderContainer {
    private OrderContainer backing;
    
    private Map<String, Map<String, Order>> typeView = new ConcurrentHashMap<>();
    
    TypeOrderContainer(OrderContainer backing) {
        this.backing = backing;
    }

    public boolean contains(String orderId) {
        return backing.contains(orderId);
    }

    public Order get(String orderId) {
        return backing.get(orderId);
    }

    public synchronized Order register(Order value) {
        String type = value.getType();
        
        Map<String, Order> innerMap = getInnerMap(type);
        innerMap.put(value.getId(), value);
        
        return backing.register(value);
    }

    private Map<String, Order> getInnerMap(String type) {
        if(!typeView.containsKey(type)) {
            return addInnerMap(type);
        } else {
            return typeView.get(type);
        }
    }

    private Map<String, Order> addInnerMap(String type) {
        Map<String, Order> innerMap = new ConcurrentHashMap<>();
        
        typeView.put(type, innerMap);
        
        return innerMap;
    }

    public synchronized Order remove(String orderId) {
        Order order = backing.remove(orderId);
        
        if(order == null) return null;
        
        String type = order.getType();
        Map<String, Order> innerMap = getInnerMap(type);
        if(innerMap == null) {
            // I suspect this is not the best error handling logic
            throw new IllegalStateException("Somehow the inner map is out of sync!!");
        } else {
            innerMap.remove(order.getId());
            // Could do this if you want, likely not necessary in my use case
            // if (innerMap.isEmpty()) typeView.removeInnerMap(); 
        }
        
        return order;
    }

    public Collection<Order> getOrders() {
        return backing.getOrders();
    }
    
    public Map<String, Order> getOrdersByType(String type) {
        return Collections.unmodifiableMap(getInnerMap(type));
    }
}

有没有更好的方法来保持数据 View 的一致性并且仍然是线程安全的？

Answer 1

我不认为#3 在你的情况下是可能的。本质上，您想要的是当 OrderContainer 中发生插入/删除时(不使用你的 TypeOrderContainer 装饰器)，你想要 TypeOrderContainer (特别是你的 typeView)同时了解插入/删除(看看那里已经有向后依赖了吗？)。如果这不是您所要求的，请忽略此答案的其余部分。

在您的情况下，您对引用的OrderContainer有一个完全独立的 View 。其中 String type 之间存在关系和Collection<Order> typedOrders正在 build 和维护中。通过 OrderContainer 中声明的方法，我们最多可以假设有 Collection<Order> allOrders 。现在让我们想象一下有 typeOrders1和typeOrders2它们一起形成allOrders 。如果我将订单插入 allOrders ，如何收集 allOrders知道哪个typeOrder放入新订单？答案是allOrders除非它理解 type --> Orders 的关系，否则不会，如果理解了，它就破坏了这个装饰器的意义。最终，子集不可能理解对原始集的更新，除非子集理解它正在寻找的范围，并且您的 allOrders 没有“类型”范围。如果你有兴趣，java的TreeSet.subSet有一个非常相似的问题，其中指定子集范围之外的任何添加都不会显示。

另一方面，我相信您的解决方案已经针对您的目的进行了良好的设计。我要做的一项优化是减少同步。唯一需要同步 typeView 的时间是在插入全新类型时:

// This assumes your maps are ConcurrentHashMaps
public Order register(Order value) { // No synchronized here since CHM does it for you
    Map<String, Order> innerMap = getInnerMap(type);
    innerMap.put(value.getId(), value);

    return backing.register(value);
}

private Map<String, Order> getInnerMap(String type) {
    if (!typeView.containsKey(type)) {
        synchronized(typeView)  {
            if (!typeView.containsKey(type)) { // make sure no one else snuck in after you "checked"
                typeView.put(type, new ConcurrentHashMap<>());
            }
        }
    }
    return typeView.get(type);
}

public Order remove(String orderId) { // No synchronized here since CHM does it for you
    Order order = backing.remove(orderId);

    if(order == null) return null;

    String type = order.getType();
    Map<String, Order> innerMap = getInnerMap(type);
    if(innerMap == null) {
        // I suspect this is not the best error handling logic
        throw new IllegalStateException("Somehow the inner map is out of sync!!");
    } else {
        innerMap.remove(order.getId());
        // Could do this if you want, likely not necessary in my use case
        // if (innerMap.isEmpty()) typeView.removeInnerMap(); 
    }

    return order;
}

public Collection<Order> getOrders() {
    return backing.getOrders();
}

public Map<String, Order> getOrdersByType(String type) {
    return Collections.unmodifiableMap(getInnerMap(type));
}

另外，一个 typical decorator pattern示例将表明这通常是可能的，因为装饰器类只是包装了支持的对象(在您的例子中为 OrderContainer backing )，并且重写的方法将添加应用于支持的对象。但是，由于您基本上是将 OrderContainer 转换(/分解)到另一个 View ，因此这对您来说不太有效。