Лучший подход к использованию в Java 6 для одновременного доступа к списку

Вам нужно использовать последовательный список? Если структура типа карты более подходящая, вы можете использовать ConcurrentHashMap. В случае списка ReadWriteLock, вероятно, является наиболее эффективным способом.

Изменить, чтобы отразить редактирование OP: Двоичный поиск по порядку вставки? Вы храните метку времени и используете ее для сравнения в бинарном поиске? Если это так, вы можете использовать метку времени в качестве ключа и ConcurrentSkipListMap в качестве контейнера (который поддерживает порядок ключей).

Что делают читающие темы? Если они повторяются по списку, вам действительно нужно убедиться, что никто не касается списка в течение всего процесса итерации, иначе вы можете получить очень странные результаты.

Если вы можете точно определить, какая семантика вам нужна, проблема должна быть решена, но вы вполне можете обнаружить, что вам нужно написать свой собственный тип коллекции, чтобы делать это правильно и эффективно. В качестве альтернативы CopyOnWriteArrayList может хорошо быть достаточно хорошим - если потенциально дорого. По сути, чем больше вы можете связать свои требования, тем эффективнее это может быть.

Я не знаю, возможно ли это решение проблемы, но ... для меня имеет смысл использовать диспетчер баз данных для хранения этого огромного количества данных и позволять ему управлять транзакциями.

Я второй предложение Telcontar базы данных, поскольку они на самом деле предназначены для управления этим масштабом данных и согласования между потоками, а коллекции в памяти - нет.

Вы говорите, что данные хранятся в базе данных на сервере, а локальный список клиентов предназначен для пользовательского интерфейса. Вам не нужно хранить все 100000 элементов на клиенте сразу или выполнять такие сложные правки. Мне кажется, что на клиенте вам нужен легкий кеш в базе данных.

Напишите кеш, в котором одновременно хранится только текущее подмножество данных на клиенте. Этот клиентский кеш не выполняет сложных многопоточных изменений собственных данных; вместо этого он передает все изменения на сервер и прослушивает обновления. Когда данные меняются на сервере, клиент просто забывает старые данные и загружает их снова. Только одному назначенному потоку разрешено читать или записывать саму коллекцию. Таким образом, клиент просто отражает правки, происходящие на сервере, вместо того, чтобы самому требовать сложных правок.

Да, это довольно сложное решение. Его составляющие:

• Протокол для загрузки диапазона данных, скажем, с 478712 по 478901, а не всего.
• Протокол для получения обновлений об измененных данных
• Класс кеша, в котором элементы хранятся по известному индексу на сервере.
• Поток, принадлежащий тому кешу, который общался с сервером. Это единственный поток, который пишет в саму коллекцию.
• Поток, принадлежащий этому кешу, который обрабатывает обратные вызовы при получении данных.
• Интерфейс, который компоненты пользовательского интерфейса реализуют, чтобы позволить им получать данные после их загрузки.

При первом ударе кости этого кеша могут выглядеть примерно так:

class ServerCacheViewThingy {
    private static final int ACCEPTABLE_SIZE = 500;
    private int viewStart, viewLength;
    final Map<Integer, Record> items
            = new HashMap<Integer, Record>(1000);
    final ConcurrentLinkedQueue<Callback> callbackQueue
            = new ConcurrentLinkedQueue<Callback>();

    public void getRecords (int start, int length, ViewReciever reciever) {
        // remember the current view, to prevent records within
        // this view from being accidentally pruned.
        viewStart = start;
        viewLenght = length;

        // if the selected area is not already loaded, send a request
        // to load that area
        if (!rangeLoaded(start, length))
            addLoadRequest(start, length);

        // add the reciever to the queue, so it will be processed
        // when the data has arrived
        if (reciever != null)
            callbackQueue.add(new Callback(start, length, reciever));
    }

    class Callback {
        int start;
        int length;
        ViewReciever reciever;
        ...
    }

    class EditorThread extends Thread {

        private void prune () {
            if (items.size() <= ACCEPTABLE_SIZE)
                return;
            for (Map.Entry<Integer, Record> entry : items.entrySet()) {
                int position = entry.key();
                // if the position is outside the current view,
                // remove that item from the cache
                ...
            }
        }

        private void markDirty (int from) { ... }

        ....
    }

    class CallbackThread extends Thread {
        public void notifyCallback (Callback callback);
        private void processCallback (Callback) {
            readRecords
        }
    }
}

interface ViewReciever {
    void recieveData (int viewStart, Record[] records);
    void recieveTimeout ();
}

Очевидно, вам придется заполнить много деталей для себя.

Вы можете использовать обертку, реализующую синхронизацию:

import java.util.Collections;
import java.util.ArrayList;

ArrayList list = new ArrayList();
List syncList = Collections.synchronizedList(list);

// make sure you only use syncList for your future calls... 

Это простое решение. Я бы попробовал это, прежде чем прибегать к более сложным решениям.