将不可修改的视图发布到内部地图

Question

I'm reading B. Goetz Java Concurrency In Practice and now I'm at the section about delegating thread safety. He provided the following example:

@Immutable
public class Point{
    public final int x, y;

    public Point(int x, int y){
        this.x = x;
        this.y = y;
    }
}

@ThreadSafe
public class DelegatingVehicleTracker {

    private final ConcurrentMap<String, Point> locations;
    private final Map<String, Point> unmodifiableMap;

    public DelegatingVehicleTracker(Map<String, Point> points){
        locations = new ConcurrentHashMap<String, Point>(points);
        unomdifiableMap = Collections.unmodifiableMap(locations);
    }

    public Map<String, Point> getLocations(){
        return unmodifiableMap;
    }

    public Point getLocation(String id){
        return locations.get(id);
    }

    public void setLocation(String id, int x, int y){
        if(locations.replace(id, new Point(x, y)) == null)
             throw new IllegalArgumentException("invalid vehicle id: " + id);
    }

}

He said that

if thread A calls getLocations and thread B later modifies the locations of some of the point, those changes are reflected in the Map returned to thread A . As we remarked earlier, this can be a benefit (more up-to-date data) or a liability (potentially inconsistent view of the fleet), depending on your requirement.

I didn't understand the drawback. Why is it possible for the view of the fleet to become inconsistent. All objects are immutable.

Answer 1

All objects are not immutable: locations is not, and so neither is unmodifiableMap .

The problem is potentially less tricky than you're looking for. Since locations is thread safe, and unmodifiableMap doesn't have any state other than an (immutable) reference to locations , there are no weird memory visibility issues.

The weirdness is that to a consumer of this class, getLocation looks like it can "magically" change values from any given thread. In other words, if a thread does this:

Point p1 = tracker.getLocation("vehicle1");
Point p2 = tracker.getLocation("vehicle1");
assert p1.equals(p2);

... then the writer of that code may be surprised that it ever fails. After all, I just got the point twice for the same vehicle, and didn't call setLocation between them — so how could the location have changed? The answer, of course, is that some other thread called setLocation , and I saw that change happen between the two calls to getLocation .

The example above is obviously a bit silly, but less silly examples aren't hard to imagine. For instance, let's say your application wants to do a snapshot of the fleet, and it assumes that two trucks can't be at the same point at the same time. This is a reasonable assumption in the physical world, but it's not one your application can make, because one truck may have moved into another truck's location between calls to getLocation :

Thread1 (taking a snapshot)             Thread2 (updating locations)
                                        setLocation("truckA", 10, 10);
                                        setLocation("truckB", 20, 20);
p1 = getLocation("truckA") // (10, 10)
                                        setLocation("truckA", 5, 10);
                                        setLocation("truckB", 10, 10);
p2 = getLocation("truckB") // (10, 10)
assert !p1.equals(p2);     // fails

As the blurb mentions, this isn't inherently bad; it all depends on your application's needs and expectations.