1

我在我的应用程序中使用 JCS 进行缓存。最近发生了一些错误，即并发访问缓存中的数据导致空值即一个线程写入缓存，一个线程读取缓存。我想知道JCS 在写入和读取缓存时是否固有地支持线程安全实现。我还想知道如何使我的实现线程安全。因为我有多个类写入缓存，比如实现 Runnable 的 PutData 用于写入缓存，而 GetData 也实现 Runnable 用于从缓存中读取，所以使方法同步没有意义，也使它们成为原子也没有意义，因为数据不在类之间共享，我将数据对象传递给各个类。顺便说一句，我使用的是 POJO 序列化类。有没有办法克服这个问题，或者我是否必须改变我的实现，使其强制完成写入然后读取，我认为这很愚蠢。

这更像是一个生产者-消费者问题，除了我的消费者线程不是在消费数据，而只是在读取数据。所以同步确实保证只有一个线程写入缓存，但这并不能解决我的问题，因为另一个线程访问不同键的对象。

期待您的回答，谢谢，Madhu。

4

2 回答 2

5

最近我开始使用 JCS，但遇到了“JCS 线程安全吗？”的问题。好吧，我查看了源代码，发现实现已经考虑了线程安全。

JCS.getInstance(String region) 总是为每个区域键返回相同的 CompositeCache 对象，包装在一个新的 JCS 对象中。换句话说，一个唯一的 CompositeCache 对象的引用保存在一个新创建的包装 JCS 对象中。当我们调用 JCS.get()、JCS.put()、JCS.remove() 等方法时，它总是会调用一个唯一的 CompositeCache 对象的方法。所以，它是单例的。

重要的是，CompositeCache 对象具有用于其写入操作（put remove 等）的同步方法，并且在内部实现中使用了 Hashtable 对象，它们也是线程安全的。所以我认为 JCS 已经在原子级别处理了线程安全。

What Thomas has mentioned above is true. If the cache object was synchronized, then a concurrency issue should have been avoided, which seems to be not the case as mentioned above, may be the issue is something else not really concurrency.

However, I just wanted to share the fact that, one should not plan to use the JCS by gaining an object level lock as discussed above, as the implementation seems to be thread safe, and we should let the concurrency to be handled at more atomic levels, looking for better performance.

于 2013-12-10T17:00:15.930 回答
0

我不知道 JCS，但您可以在对象上进行同步，因此您可能希望在缓存对象上进行同步。

像这样：

public void putToCache(...) { 
  synchronized (cache) { //cache is your actual cache instance here
   //put to cache here
  }
}
于 2011-12-12T12:54:33.297 回答