正确使用锁保护共享数据，协调异步线程
JMQ为提升性能，使用近乎无锁的设计：
- MQ中的锁是个必须使用的技术
- 使用锁会降低系统性能
如何正确使用锁？
异步和并发设计可大幅提升性能，但程序更复杂：多线程执行时，充斥不确定性。对一些需并发读写的共享数据，一着不慎满盘皆输。
案例：团建
老板说：“部门准备团建，愿意参加的回消息报名，统计下人数。都按我规定格式报名。” 老板发了：“A，1人”。这时候B和C都要报名，过一会儿，他俩几乎同时各发了一条消息，“B，2人”“C，2人”，每个人发的消息都只统计了老板和他们自己，一共2人，而这时，其实已经有3个人报名了，并且，在最后发消息的C的名单中，B的报名被覆盖。
典型并发读写导致的数据错误。使用锁可有效解决：任何时间都只能有一个线程持锁，持锁线程才能访问被锁保护的资源。
团建案例中，可认为群中有把锁，想要报名的人必须先拿到锁，然后才能更新名单。这就避免了多人同时更新消息，报名名单也就不会出错了。
避免滥用锁
难道遇到这种情况都用锁？ 如果能不用锁，就不用锁； 如果你不确定是不是应该用锁，那也不要用锁。
因为使用锁虽然可以保护共享资源，但代价不小。
- 加锁和解锁都要CPU时间，这是性能损失。另外，使用锁就有可能导致线程等待锁，等待锁过程中线程是阻塞的状态，过多的锁等待会显著降低程序的性能
- 如果锁使用不当，很容易死锁，导致程序卡死。多线程本就难以调试，再加锁，出现并发问题或者死锁问题，程序更难调试。
所以，你在使用锁以前，一定要非常清楚明确地知道，这个问题必须要用一把锁来解决。切忌看到一个共享数据，也搞不清它在并发环境中会不会出现争用问题，就“为了保险，给它加个锁吧。”千万不能有这种不负责任的想法，否则你将会付出惨痛的代价！我曾经遇到过的严重线上事故，其中有几次就是由于不当地使用锁导致的。
只有并发下的共享资源不支持并发访问，或者并发访问共享资源会导致系统错误的情况下，才需使用锁。
锁的用法
在访问共享资源之前，先获取锁。 如果获取锁成功，就可以访问共享资源了。 最后，需要释放锁，以便其他线程继续访问共享资源。
Java使用锁
private Lock lock = new ReentrantLock();
public void visitShareResWithLock() {
lock.lock();
try {
// 在这里安全的访问共享资源
} finally {
lock.unlock();
}
}也可以使用synchronized关键字，它的效果和锁是一样的：
private Object lock = new Object();
public void visitShareResWithLock() {
synchronized (lock) {
// 在这里安全的访问共享资源
}
}使用锁要注意： 使用完锁一定要释放。若在访问共享资源时抛异常，后面释放锁代码就不会再执行，导致死锁。所以要考虑代码可能走的所有分支，确保所有情况下的锁都能释放。
接下来我们说一下，使用锁的时候，遇到的最常见的问题：死锁。
避免死锁
- 死锁 由于某种原因，锁一直没释放，后续需要获取锁的线程都将处于等待锁的状态，这样程序就卡死。
导致死锁的原因不多
- 获取锁后没释放，有经验的程序员很少犯这种错误，即使出现也很容易解决
- 锁的重入 看下面代码：
public void visitShareResWithLock() {
lock.lock(); // 获取锁
try {
lock.lock(); // 再次获取锁，会导致死锁吗？
} finally {
lock.unlock();
}当前的线程获取到了锁lock，然后在持有这把锁的情况下，再次去尝试获取这把锁，这样会导致死锁吗？ 不一定。会不会死锁取决于，你获取的这把锁它是不是可重入锁。如果是可重入锁，那就没有问题，否则就会死锁。
大部分编程语言都提供了可重入锁，若无特别要求，尽量使用可重入锁。因为若程序复杂，调用栈很深，很多情况下，当需要获取一把锁时，你不太好判断在n层调用之外的某个地方，是不是已经获取过这把锁，这时，获取可重入锁就有必要。
最后一种死锁的情况是最复杂的，也是最难解决的。如果你的程序中存在多把锁，就有可能出现这些锁互相锁住的情况。 模拟最简单最典型的死锁情况。在这个程序里面，我们有两把锁：lockA和lockB，然后我们定义了两个线程，这两个线程反复地去获取这两把锁，然后释放。 程序执行一会儿就卡住了，发生死锁。 他们获取锁的顺序不一样。 第一个线程，先获取lockA，再获取lockB； 第二个线程正好相反，先获取lockB，再获取lockA。 这最简单的两把锁两个线程死锁的情况，还可以分析清楚，如果你的程序中有十几把锁，几十处加锁解锁，几百线程，如果出现死锁你还能分析清楚是什么情况吗？
避免死锁
- 程序尽量少用锁
- 同把锁，加锁和解锁必须放在同一方法
- 尽量避免同时持有多把锁，即持有一把锁时，又去获取另外一把锁
- 若需要持多把锁，注意加解锁顺序，解锁顺序要和加锁顺序相反
- 给你程序中所有的锁排一个顺序，在所有需要加锁的地方，按照同样的顺序加解锁。 如果两个线程都按照先获取lockA再获取lockB的顺序加锁，就不会产生死锁。
使用读写锁
共享数据，如果某方法访问它时，只读取，并不更新，就不需要加锁？ 还是需要的，因为如果一个线程读时，另外一个线程同时在更新，那么你读数据有可能是更新到一半的。 所以，无论只读还是读写访问，都是需要加锁的。
锁虽然解决安全问题，但牺牲性能无法并发。
若无线程在更新，即使多线程并发读，也没问题。大部分情况下，数据读要远多于写，所以，我们希望的是：
读可并发执行。 写的同时不能并发读，也不能并发写。 这就兼顾性能和安全。读写锁就为这此而设计。 Java读写锁实例
ReadWriteLock rwlock = new ReentrantReadWriteLock();
public void read() {
rwlock.readLock().lock();
try {
// 在这儿读取共享数据
} finally {
rwlock.readLock().unlock();
}
}
public void write() {
rwlock.writeLock().lock();
try {
// 在这儿更新共享数据
} finally {
rwlock.writeLock().unlock();
}
}需要读数据的时候，我们获取读锁，不是互斥锁，read()方法可多线程并行执行，这使读性能很好。 写数据，获取写锁，当一个线程持有写锁，其他线程既无法获取读锁，也不能获取写锁，从而保护共享数据。
如此读写锁就兼顾了性能和安全。
在Java中实现一个try-with-lock呢？
java7开始io就有try-with-resource。
可以利用这一个特性，来说实现，自动释放。
代码如下：
public class AutoUnlockProxy implements Closeable {
private Lock lock;
public AutoUnlockProxy(Lock lock) {
this.lock = lock;
}
@Override
public void close() throws IOException {
lock.unlock();
System.out.println("释放锁");
}
public void lock() {
lock.lock();
}
public void tryLock(long time, TimeUnit unit) throws InterruptedException {
lock.tryLock(time, unit);
}
public static void main(String[] args) {
try (AutoUnlockProxy autoUnlockProxy = new AutoUnlockProxy(new ReentrantLock())) {
autoUnlockProxy.lock();
System.out.println("加锁了");
} catch (IOException e) {
e.printStackTrace();
}
}
}