How do I lock a data structure (such as List) when someone is iterating over it?

For example, let's say I have this class with a list in it:

 class A{
     private List<Integer> list = new ArrayList<>();

     public MyList() {
         // initialize this.list
     }

    public List<Integer> getList() {
        return list;
    }
}

And I run this code:

public static void main(String[] args) {
    A a = new A();

    Thread t1 = new Thread(()->{
        a.getList().forEach(System.out::println);
    });
    Thread t2 = new Thread(()->{
        a.getList().removeIf(e->e==1);
    });

    t1.start();
    t2.start();
}

I don't have a single block of code that uses the list, so I can't use synchronized().

I was thinking of locking the getList() method after it has been called but how can I know if the caller has finished using it so I could unlock it?

And I don't want to use CopyOnWriteArrayList because of I care about my performance;

CodePudding user response：

after it has been called but how can I know if the caller has finished using it so I could unlock it?

That's impossible. The iterator API fundamentally doesn't require that you explicitly 'close' them, so, this is simply not something you can make happen. You have a problem here:

Iterating over the same list from multiple threads is an issue if anybody modifies that list in between. Actually, threads are immaterial; if you modify a list then interact with an iterator created before the modification, you get ConcurrentModificationException guaranteed. Involve threads, and you merely usually get a CoModEx; you may get bizarre behaviour if you haven't set up your locking properly.

Your chosen solution is "I shall lock the list.. but how do I do that? Better ask SO". But that's not the correct solution.

You have a few options:

Use a lock

It's not specifically the iteration that you need to lock, it's "whatever interacts with this list". Make an actual lock object, and define that any interaction of any kind with this list must occur in the confines of this lock.

Thread t1 = new Thread(() -> {
  a.acquireLock();
  try {
    a.getList().forEach(System.out::println);
  } finally {
    a.releaseLock();
  }
});

t1.start();

Where acquireLock and releaseLock are methods you write that use a ReadWriteLock to do their thing.

Use CopyOnWriteArrayList

COWList is an implementation of java.util.List with the property that it copies the backing store anytime you change anything about it. This has the benefit that any iterator you made is guaranteed to never throw ConcurrentModificationException: When you start iterating over it, you will end up iterating each value that was there as the list was when you began the iteration. Even if your code, or any other thread, starts modifying that list halfway through. The downside is, of course, that it is making lots of copies if you make lots of modifications, so this is not a good idea if the list is large and you're modifying it a lot.

Get rid of the getList() method, move the tasks into the object itself.

I don't know what a is (the object you call .getList() on, but apparently one of the functions that whatever this is should expose is some job that you really can't do with a getList() call: It's not just that you want the contents, you want to get the contents in a stable fashion (perhaps the method should instead have a method that gives you a copy of the list), or perhaps you want to do a thing to each element inside it (e.g. instead of getting the list and calling .forEach(System.out::println) on it, instead pass System.out::println to a and let it do the work. You can then focus your locks or other solutions to avoid clashes in that code, and not in callers of a.

Make a copy yourself

This doesn't actually work, even though it seems like it: Immediately clone the list after you receive it. This doesn't work, because cloning the list is itself an operation that iterates, just like .forEach(System.out::println) does, so if another thread interacts with the list while you are making your clone, it fails. Use one of the above 3 solutions instead.