分析
背景:DN性能优化的一部分
目标:AutoCloseableLock 改为 ReadWriteLock
知识回顾:假设在程序中定义一个共享的数据结构,它大部分时间提供读服务,而写操作占有的时间很少,但是写操作完成之后的更新需要对后续的读服务可见。在没有写操作的时候,两个线程同时读一个资源没有任何问题,所以应该允许多个线程能在同时读取共享资源。但是如果有一个线程想去写这些共享资源,就不应该再有其它线程对该资源进行读或写(也就是说:读-读能共存,读-写不能共存,写-写不能共存)。这就需要一个读/写锁来解决这个问题。
ReentrantReadWriteLock的实现里面重要特性:1、公平性:非公平锁(默认):非公平锁的吞吐量要高于公平锁。(公平锁概念:公平锁利用AQS的CLH队列,释放当前保持的锁时,优先为等待时间最长的那个写操作分配写入锁)
代码实现
Hadoop自定义实现了一套支持try-with-resource的锁。如下:
public class AutoCloseableLock implements AutoCloseable {
private final Lock lock;
public AutoCloseableLock() {
this(new ReentrantLock());
}

博客介绍了在Hadoop中,为了优化性能,将全局的排它锁(ReentrantLock)替换为读写锁(ReentrantReadWriteLock)。改动包括将datasetLock替换为datasetWriteLock和datasetReadLock,并在代码中相应地使用写锁。虽然目前所有访问都使用写锁,行为与原锁相同,但这作为拆锁的第一步,为后续引入读锁以提高并发读性能铺平道路。改动已通过单元测试,但必须配合后续补丁才能实现性能提升。
最低0.47元/天 解锁文章
1803

被折叠的 条评论
为什么被折叠?



