性能和锁的问题

spikeme
高性能的系统设计上一般都会考虑缓存，根据我的了解，一般高性能跟锁是矛盾的，比如要实现高性能，并发问题就很难解决。并发问题解决了。性能就降低了，好象一直矛盾，解决不了。比如用hashmap做缓存，hashmap本身就是非线程安全的，在多线程环境中运行，肯定有问题。但是如果加了锁处理。性能明显下降。大家说说有没有什么好的解决办法。
xmuzyu 2009-04-26 12:15
锁的粒度与性能才会有很大的关系。如果锁的粒度控制的好，不会看到性能明显的下将的。过去我们以来数据库的事务锁来控制并发访问和事务的完整性，而当今我们可以通过内存业务对象控制并发访问，事务只是用来保证完整性。

所以设计锁一定要注意mutex保护的临界区应该尽量的小，并且可以采用锁分离技术，采用粒度更加细的锁。而要想真正的减轻并发控制带来的头痛，那请我们设计好我们的业务对象，把状态封装好，封装的越好，并发控制就越容易。

spikeme 2009-04-26 14:41
谢谢楼上回复。
所以设计锁一定要注意mutex保护的临界区应该尽量的小，并且可以采用锁分离技术，采用粒度更加细的锁？ 这个我赞成。

而要想真正的减轻并发控制带来的头痛，那请我们设计好我们的业务对象，把状态封装好，封装的越好，并发控制就越容易。？？？ 我觉得实际操作起来比较困难。不过楼上能说得更详细更具体就更好了。

不过JDK1。6好象对锁进行了优化，特别是以前的同步处理，很耗费开销。在JDK1。6和JDK1。5下进行了测试，确实有了性能上的提升。

xmuzyu 2009-04-26 15:00
这个设计到共享对象在并发环境下的安全发布问题。要想做好对共享对象的安全发布，对对象的封装时必需的。举个例子，比如a对象有个状态b,我们只有封装了对b状态的所有访问，这样才方便并发控制，例如，我们可以通过a.changeState()来改变状态，而不要暴漏b给外界，这样的话，整个系统中，对b的更新就散乱了，而如果我们通过changeState()来改变的话，并发情况下，我们只需要采用细粒度的锁，对changeState()进行控制就OK了。
所以我觉得DDD中的聚合时非常的重要，一个系统如果没有设计好聚合，那么真个系统中的对象都是散乱分布的，没有办法控制对业务对象的并发访问，也更加没有办法对业务对象的全局缓存进行并发控制。

ps:上面是关于如何在并发情况下控制共享对象的情况，主要就是封装，和细粒度的锁，而对于并发，我们还可以采用另外一种方法那就是，线程限制，也就是不共享变量，比如把变量设置为局部变量，这样就在线程栈中，或者采用JAVA中的ThreadLocal.