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

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

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

Жду ваших ответов, спасибо, Мадху.

Источник

2 ответа

Решение

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

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

public void putToCache(...) { 
  synchronized (cache) { //cache is your actual cache instance here
   //put to cache here
  }
}
Источник

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

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

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

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

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

Источник
Другие вопросы по тегам