Ошибка параллелизма JCS

Question

Я использую JCS для кэширования в моем приложении. В последнее время возникают некоторые ошибки, когда одновременный доступ к данным в кэше приводит к нулевому значению , т.е. один поток записывает в кэш, а один поток читает в кэш .Я хочу знать, поддерживает ли JCS изначально поточно-ориентированные реализации при записи и чтении из кэша. Я также хочу знать, как сделать поток моей реализации безопасным. Поскольку у меня есть несколько классов, пишущих в кеш, скажем, PutData, который реализует Runnable, используется для записи в кеш, а GetData, который также реализует Runnable для чтения из кеша, поэтому синхронизированный метод не имеет смысла, а также делает их атомарными и не имеет смысла, поскольку данные не распределяются между классами, и я передаю объект данных отдельным классам. Кстати, я использую сериализованный класс POJO. Есть ли способ преодолеть это, или я должен изменить свою реализацию так, чтобы она принудительно заканчивала написание, а затем чтение, что я считаю глупым.

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

Ожидая ваших ответов, Спасибо, Мадху.

Answer 1

Недавно я начал использовать JCS, и у меня возникла проблема «Безопасен ли поток JCS?». Ну, я взглянул на исходный код и обнаружил, что реализация учитывает безопасность потоков.

JCS.getInstance (String region) всегда возвращает один и тот же объект CompositeCache для каждого ключа региона, заключенного в новый объект JCS. Другими словами, ссылка на единственный объект CompositeCache сохраняется во вновь созданном объекте JCS-обертки. Когда мы вызываем такие методы, как JCS.get (), JCS.put (), JCS.remove () и т. Д., Это всегда заканчивается вызовом метода единственного объекта CompositeCache. Итак, это синглтон.

Важно, что объект CompositeCache имеет синхронизированные методы для своих операций записи (вставка, удаление и т. Д.), А во внутренней реализации используются объекты Hashtable, которые также являются поточно-ориентированными. Поэтому я думаю, что JCS позаботился о безопасности потоков на атомных уровнях.

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

Однако я просто хотел бы поделиться тем фактом, что не следует планировать использовать JCS, получая блокировку уровня объекта, как обсуждалось выше, так как реализация кажется поточно-ориентированной, и мы должны позволить обрабатывать параллелизм на более атомных уровнях, в поисках лучшей производительности.

Answer 2

Я не знаю JCS, но вы можете синхронизировать на объектах, поэтому вы можете синхронизировать на объекте кеша.

Примерно так:

public void putToCache(...) { 
  synchronized (cache) { //cache is your actual cache instance here
   //put to cache here
  }
}