3.4 行锁
像put()、delete()、checkAndPut()这样的修改操作是独立执行的，这意味着在一个串行方式的执行中，对于每一行必须保证行级别的操作是原子性的。region服务器提供了一个行锁（row lock）的特性，这个特性保证了只有一个客户端能获取一行数据相应的锁，同时对该行进行修改。在实践中，大部分客户端应用程序都没有提供显式的锁，而是使用这个机制来保障每个操作的独立性。
文字用户应该尽可能地避免使用行锁。就像在RDBMS中，两个客户端很可能在拥有对方要请求的锁时，又同时请求对方已拥有的锁，这样便形成了一个死锁。
锁超时之前，两个被阻塞的客户端会占用一个服务器端的处理线程（handler），而这个线程是一种十分稀缺的资源。如果在一个频繁操作的行上发生了这种情况，那么很多其他的客户端会占用掉其所有的处理线程，阻塞所有其他客户端访问这台服务器，导致这个region服务器将不能为其负责的region内的行提供服务。
重申一下：在不必要的情况下，尽量不要使用行锁。如果必须使用，那么一定要节约占用锁的时间！
比如，当使用put()访问服务器时，Put实例可以通过以下构造函数生成：
Put(byte[] row)
这个构造函数就没有RowLock实例参数，所以服务器会在调用期间创建一个锁。实际上，通过客户端的API，得不到这个生存期短暂的服务器端的锁的实例。
除了服务器端隐式加锁之外，客户端也可以显式地对单行数据的多次操作进行加锁，通过以下调用便可以做到：
RowLock lockRow(byte[] row) throws IOException
void unlockRow(RowLock rl) throws IOException
第一个调用lockRow()需要一个行键作为参数，返回一个RowLock的实例，这个实例可以供后续的Put或者Delete的构造函数使用。一旦不再需要锁时，必须通过unlockRow()调用来释放它。
每一个排他锁（unique lock），无论是由服务器提供的，还是通过客户端API传入的，都能保护这一行不被其他锁锁定。换句话说，锁必须针对整个行，并且指定其行键，一旦它获得锁定权就能防止其他的并发修改。
当一个锁被服务器端或客户端显式获取之后，其他所有想要对这行数据加锁的客户端将会等待，直到当前锁被释放，或者锁的租期超时。后者是为了确保错误进程不会占用锁太长时间或无限期占用。
图像说明文字默认的锁超时时间是一分钟，但是可以在hbase-site.xml文件中添加以下配置项来修改这个默认值，时间以毫秒为单位：
< property>
< name>hbase.regionserver.lease.period< /name>
< value>120000< /value>
< /property>
通过添加以上代码，超时时间被设置为原来的两倍——120秒也就是2分钟。小心不要将这个值设得太大，因为每一个想获取被锁住的行的客户端都会阻塞并等待锁的恢复。
例3.17展示了如何在行上创建一个锁，该锁阻塞所有的并发读取。
例3.17 显式使用行锁
static class UnlockedPut implements Runnable {
@Override
public void run() {
try {
HTable table = new HTable(conf,"testtable");
Put put = new Put(ROW1);
put.add(COLFAM1,QUAL1,VAL3);
long time = System.currentTimeMillis();
System.out.println("Thread trying to put same row now...");
table.put(put);
System.out.println("Wait time: " +
(System.currentTimeMillis() - time)+ "ms");
} catch(IOException e){
System.err.println("Thread error: " + e);
}
}
}
System.out.println("Taking out lock...");
RowLock lock = table.lockRow(ROW1);
System.out.println("Lock ID: " + lock.getLockId());
Thread thread = new Thread(new UnlockedPut());
thread.start();
try {
System.out.println("Sleeping 5secs in main()...");
Thread.sleep(5000);
} catch(InterruptedException e){
// ignore
}
try {
Put put1 = new Put(ROW1,lock);
put1.add(COLFAM1,QUAL1,VAL1);
table.put(put1);
Put put2 = new Put(ROW1,lock);
put2.add(COLFAM1,QUAL1,VAL2);
table.put(put2);
} catch(Exception e){
System.err.println("Error: " + e);
} finally {
System.out.println("Releasing lock...");
table.unlockRow(lock);
}
使用一个异步的线程更新同一个行，但是不显式加锁。
put()调用会阻塞，直到锁被释放。
给整行加锁。
启动那个会阻塞的异步线程。
休眠一会儿，以阻塞其他写入操作。
在拥有锁的情况下创建Put。
在拥有锁的情况下创建另外一个Put。
释放锁，让阻塞线程继续执行。
执行这个例子代码时，应该能在控制台看到以下输出：
Taking out lock...
Lock ID: 4751274798057238718
Sleeping 5secs in main()...
Thread trying to put same row now...
Releasing lock...
Wait time: 5007ms
After thread ended...
KV: row1/colfam1:qual1/1300775520118/Put/vlen=4,Value: val2
KV: row1/colfam1:qual1/1300775520113/Put/vlen=4,Value: val1
KV: row1/colfam1:qual1/1300775515116/Put/vlen=4,Value: val3
从这个例子能看出，一个显示的锁是如何阻塞另一个使用隐式锁的线程的。主线程休眠了5秒，一醒来就调用了两次put()，分别将同一列设置为两个不同的数值。
主线程的锁一释放，阻塞线程的run()方法就继续执行并调用了第三个put。观察put操作在服务器端的执行情况，会觉得很有意思。读者可能注意到了，KeyValue实例的时间戳显示第三个put拥有最小的时间戳，虽然这个put表面上是最后执行的。这是因为线程中的put()调用是在两个主线程中的put()之前执行的，这之后主线程休眠了5秒。当put被发送到服务器时，如果它的时间戳没有被显式指定，服务器端会帮它设定时间戳，同时试图获得这一行的锁。但是示例代码中主线程已经获得了该行的锁，因此服务器端的处理一直等待了5秒多，锁被释放才得已继续。从上面的输出可以看出，主线程中两个put调用的执行以及行的解锁只花费了7毫秒的时间。
Get需要锁吗？
修改行时锁定行是有意义的，那么获取数据时是否需要加锁呢？Get类有一个构造器允许用户指定一个显式的锁：
Get(byte[] row,RowLock rowLock)
这是遗留的方法，但服务器端根本用不着这种方法，因为在获取数据的过程中，服务器根本不需要任何锁，而是应用了一个多版本的并发控制（multiversion concurrencycontrol-style）⑦机制来保证行级读操作。例如，get()调用永远不会返回写了一半的数据，比如当这些数据是另一个线程或者客户端写的。
这个就像是小规模的事务系统：只有当一个变动被应用到整个行之后，客户端才能读出这个改动。当改动在进行中时，所有的客户端读取操作得到的都将是所有列以前的状态。
当用户试图使用之前申请的显式锁，但锁的租约已经超时并恢复，用户将会从服务器得到一个以UnknownRowLockException形式报告的错误。这个异常告诉用户服务器已经废弃了用户尝试使用的锁。用户应该在代码中丢弃这个锁，然后请求一个新的锁再试图恢复锁定状态。