性能和锁的问题

高性能的系统设计上一般都会考虑缓存,根据我的了解,一般高性能跟锁是矛盾的,比如要实现高性能,并发问题就很难解决。并发问题解决了。性能就降低了,好象一直矛盾,解决不了。比如用hashmap做缓存,hashmap本身就是非线程安全的,在多线程环境中运行,肯定有问题。但是如果加了锁处理。性能明显下降。大家说说有没有什么好的解决办法。

锁的粒度与性能才会有很大的关系。如果锁的粒度控制的好,不会看到性能明显的下将的。过去我们以来数据库的事务锁来控制并发访问和事务的完整性,而当今我们可以通过内存业务对象控制并发访问,事务只是用来保证完整性。

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

谢谢楼上回复。
所以设计锁一定要注意mutex保护的临界区应该尽量的小,并且可以采用锁分离技术,采用粒度更加细的锁? 这个我赞成。

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

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

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

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