Я читаю файлы журнала, но не все строки нужно обрабатывать сразу. Я использую очередь / буфер для хранения строк, пока они ждут обработки.
Эта очередь регулярно сканируется на предмет определенных строк - когда они обнаруживаются, они удаляются из очереди (они могут находиться где угодно в ней). Когда не удается найти конкретную строку, строки по одной берутся из начала очереди для обработки.
Следовательно, очереди необходимо следующее:
Я изначально написал код, когда у меня был небольшой опыт работы с Java или API, и просто использовал ArrayList, потому что знал, что он будет работать (не обязательно потому, что это лучший вариант).
Его производительность сейчас ухудшается, и требуется обрабатывать все больше и больше журналов. Итак, какую коллекцию вы бы порекомендовали использовать в этой ситуации? Всегда есть возможность написать свое собственное.
Спасибо
LinkedList, вероятно, будет наиболее подходящим. Он имеет все требуемые свойства и позволяет удалять ссылки из середины за постоянное время, а не за линейное время, необходимое для ArrayList.
Если у вас есть какая-то конкретная стратегия для поиска следующего элемента, который нужно удалить, PriorityQueue или даже отсортированный набор могут быть более подходящими.
Это будет одним из недостатков LinkedList, потенциально медленным поиском.
Поиск в связанном списке зависит от типа поиска. Пройти через все довольно просто, а удаление - тривиально.
По-разному; да, поиск будет медленным (иш), но если он потенциально удаляет несколько элементов при каждом поиске, более дешевые удаления будут стоить более медленного поиска. С другой стороны, если цели для удаления редки и редки, это может быть не лучшим решением.
Быстрое сканирование обычно подразумевает какую-то реализацию на основе хэша, ConcurrentSkipListMap может быть хорошей реализацией. Log (n) в методах containskey, remove и get и отсортирован так, чтобы с ним можно было связать какой-то приоритет.
Поскольку вам нужно удалять и добавлять элементы из набора и искать определенные значения, возможно, лучшей структурой может быть что-то, что реализует SortedSet, например TreeSet. Этот класс гарантирует производительность log (n) при добавлении, удалении и содержании.
Я предполагаю, что некоторые потоки будут писать в очередь, а другой будет читать из нее.
В этом случае вам следует посмотреть очереди в пакете java.lang.concurrent.
Вы можете использовать PriorityBlockingQueue, чтобы позволить ему упорядочить элементы за вас, или LinkedBlockingQueue, если вы хотите перебирать его и выбирать элементы для удаления.
Я не хочу сортировать читаемые строки (их нужно сохранять в исходном порядке). Однако я потенциально мог заблокировать строки на основе идентификатора сеанса, который есть у каждой записываемой строки (несколько записываемых строк на сеанс).
Думая об этом, я потенциально мог бы иметь:
HashMap<String,LinkedList<String>>
и укажите идентификатор сеанса в качестве ключа и заполните LinkedList строками, принадлежащими сеансу.
Карта предоставит быстрый способ поиска строк, связанных с сеансом X, а затем связанный список обеспечит лучшую производительность для добавления / удаления строк (эффективность поиска заключалась в поиске строк, связанных с сеансом x, поэтому фактические строки что делать с сеансом x можно прочитать и удалить от начала до конца - нажал / выскочил).
Есть ли лучшая коллекция, чем связанный список, который изменял бы размер, добавлял строки в конце и всегда брался с начала? Я считаю, что коллекция Queue все равно расширяет связанный список?
LinkedHashSet может быть интересен. По сути, это HashSet, но он также поддерживает LinkedList, чтобы обеспечить предсказуемый порядок итераций - и, следовательно, также может использоваться в качестве очереди FIFO с приятным дополнительным преимуществом, заключающимся в том, что он не может содержать повторяющиеся записи.
Поскольку это тоже HashSet, поиск (в отличие от сканирования) может иметь значение O (1), если они могут соответствовать на equals()
.
Это дает лучшее из обоих миров. Спасибо, что ознакомили меня с этой коллекцией, иначе я бы никогда не подумал об этом: 0)
Я сам неоднократно создавал эту коллекцию, прежде чем она была добавлена в SDK, она невероятно полезна (и для ее написания самостоятельно из HashSet и LinkedList требуется всего несколько строк кода).
Я согласен с AVI, и связанный список будет вашим лучшим вариантом. Вы можете легко изменить размер, быстро добавить в конец списка, быстро удалить откуда угодно. Поиск не будет быстрым, но не хуже, чем в любом другом несортированном списке.
Гуава может помочь.
The Guava project contains several of Google's core libraries that we rely on in our Java-based projects: collections, caching, primitives support, concurrency libraries, common annotations, string processing, I/O, and so forth.
Разве связанный список не будет медленным при поиске удаляемых элементов?