共计 4474 个字符，预计需要花费 12 分钟才能阅读完成。
在上篇文章中，咱们提到了活锁是一个很少呈现、危害很小的 BUG。更何况，活锁即便呈现了，最多等个一两秒就主动解开，基本不算大问题。
然而，除了活锁，还有一种状况，你只有没解决好，程序很可能一下就解体掉，这就是 饥饿。
什么是饥饿
饥饿，就是线程拿不到须要的资源，始终没法执行。比如说，上面这段代码：
class Account {
// 余额
private Integer balance;
// 转账
void transfer(Account target, Integer amt) {synchronized (Account.class) {
// 本零碎操作：批改余额，破费 0.01 秒
if (this.balance > amt) {
this.balance -= amt;
target.balance += amt;
}
// 调用内部零碎：转账，破费 5 秒
payService.transfer(this, target, amt);
}
}
}咱们如果想要转账，那么就得先锁定 Account.class。当锁定胜利后，就批改两个账户的余额。最初，咱们再调用银行的接口，让钱真正达到银行账户，这笔转账才算实现。
这段代码十分完满，只有十几笔交易进来，就能扣掉你半个月的工资。起因出在哪呢？这段代码的效率切实太低了。
无论你电脑的配置有多好，转账都得花 5 秒的工夫，效率还是很慢。这就算了，要害是每次只能解决一笔转账，其它交易只能干等着。最致命的是，解决完一笔交易后，下一笔轮到谁齐全不晓得。
看到这儿，饥饿是怎么一回事，你大略能明确了吧？简略来说，饥饿就是程序自身没有问题，但资源太少，始终没机会运行。
如果你还是有点懵，能够设想这么一个场景：十几个人找你借钱，但钱就这么多。于是，你先借给一个人，等他还回来后，再看情绪轻易借给另一个人。
在并发编程畛域，饥饿是最常常碰到的问题。而且，如果你不了解具体的业务，很可能连问题出在哪儿都不晓得。
如何解决饥饿问题
咱们曾经晓得，所谓饥饿，就是资源太少，线程拿不到资源，始终没机会运行。
换句话说，饥饿问题都是由资源太少导致的。那么，又是什么起因导致资源太少的呢？咱们还是看看下面的转账代码。
class Account {
// 余额
private Integer balance;
// 转账
void transfer(Account target, Integer amt) {synchronized (Account.class) {
// 本零碎操作：批改余额，破费 0.01 秒
if (this.balance > amt) {
this.balance -= amt;
target.balance += amt;
}
// 调用内部零碎：转账，破费 5 秒
payService.transfer(this, target, amt);
}
}
}首先，资源有余。Account.class只有一个，所以转账只能一笔一笔地解决。
而后，调配不均。synchronized是非偏心锁，先解决哪笔交易齐全是随机的，先来的转账可能最初才解决。
最初，耗时太长。调用内部零碎，这个操作切实是太浪费时间了。
能够说，这段转账的代码集齐了所有故障，轻易解决一个都够让你升职加薪了。
既然问题曾经找到了，解决思路天然也有了，别离是这么几个：
- 保障资源短缺；
- 偏心地分配资源；
- 缩小线程的执行工夫；
接下来，咱们别离照着这几个思路，看看怎么优化这个转账性能。
如何保障资源短缺？
咱们先来温习转账的代码：
class Account {
// 余额
private Integer balance;
// 转账
void transfer(Account target, Integer amt) {synchronized (Account.class) {
// 本零碎操作：批改余额，破费 0.01 秒
if (this.balance > amt) {
this.balance -= amt;
target.balance += amt;
}
// 调用内部零碎：转账，破费 5 秒
payService.transfer(this, target, amt);
}
}
}这段代码中，要想转账就必须锁定 Account.class，但 Account.class 只有一个，速度无论如何都没法进步。
换句话说，零碎的资源总是稀缺的，这个问题看似无解。但转账真的要锁住整个 Account.class 吗？
不须要！你认真想，一笔转账只波及两个账户，其它的交易只有不波及到这两个账户，就齐全能够并行处理。当初倒好，整个 Account.class 被锁住了，转账只能一笔一笔地解决，效率当然没法看。
比如说，当初有两笔交易，别离是：账户 A 转 账户 B 、账户 C 转 账户 D 。那这两笔交易齐全没有关联，即便同时解决也不会有问题，你不须要把整个银行给锁了。
既然问题找到了，咱们间接改代码：
class Account {
// 余额
private Integer balance;
// 转账
void transfer(Account target, Integer amt) {synchronized (this) {synchronized (target) {
// 本零碎操作：批改余额，破费 0.01 秒
if (this.balance > amt) {
this.balance -= amt;
target.balance += amt;
}
// 调用内部零碎：转账，破费 5 秒
payService.transfer(this, target, amt);
}
}
}
}整段代码也没什么变动，咱们只锁定了两个账户：this、target，多用了一个 synchronized。这看似非常简单，但只有账户不抵触，转账就能并行处理，整体的效率高了几十个品位。
这样一来，资源有余的问题就被大大地缓解，咱们保障了资源短缺。
如何偏心地分配资源？
咱们持续来看转账的代码：
class Account {
// 余额
private Integer balance;
// 转账
void transfer(Account target, Integer amt) {synchronized (Account.class) {
// 本零碎操作：批改余额，破费 0.01 秒
if (this.balance > amt) {
this.balance -= amt;
target.balance += amt;
}
// 调用内部零碎：转账，破费 5 秒
payService.transfer(this, target, amt);
}
}
}这段代码中，咱们为了解决程序的原子性问题，用到 Java 的关键字 synchronized，这算是最简略的计划了。
然而，synchronized 是非偏心锁，这可能导致某些线程始终没法执行。什么意思呢？
失常状况下，如果进来了好几笔交易，那么得讲个先来后到，谁期待的工夫长就先解决。不过，如果你用的是synchronized，那么程序齐全是随机的，可能等待时间短的交易反而先解决，等待时间长的始终不解决。
在交易量不算特地大的时候，转账慢点其实还能承受，但如果一笔交易进来，你齐全搞不清什么时候能实现，这就说不过去了。想解决这个问题，咱们得用到 Java 并发包的货色。
class Account {
// 余额
private Integer balance;
// 创立一把偏心锁
private final Lock rtLock = new ReentrantLock(true);
// 转账：代码大大简化，请勿模拟
void transfer(Account33 target, int amt) {if (this.rtLock.tryLock()) {if (target.rtLock.tryLock()) {
// 本零碎操作：批改余额，破费 0.01 秒
if (this.balance > amt) {
this.balance -= amt;
target.balance += amt;
}
// 调用内部零碎：转账，破费 5 秒
payService.transfer(this, target, amt);
target.rtLock.unlock();}
this.rtLock.unlock();}
}
}在这里，线程如果想要转账，就必须拿到两个账户的锁。但不同的是，这次咱们创立了一把偏心锁，没拿到锁的线程会进入期待队列，当有线程开释锁的时候，会唤醒一个线程。这时候，谁期待的工夫长，就先唤醒谁。
这样一来，咱们保障了资源的调配最起码是偏心的。
如何缩小线程的执行工夫？
咱们最初再看一眼转账的代码：
class Account {
// 余额
private Integer balance;
// 转账
void transfer(Account target, Integer amt) {synchronized (Account.class) {
// 本零碎操作：批改余额，破费 0.01 秒
if (this.balance > amt) {
this.balance -= amt;
target.balance += amt;
}
// 调用内部零碎：转账，破费 5 秒
payService.transfer(this, target, amt);
}
}
}这段代码中，咱们有两个操作：一个是批改余额，另一个是调用内部零碎。只有实现这两个操作，一笔转账才算实现。
然而，你有没有发现，调用内部零碎，这个操作消耗的工夫太长了。而且，这个内部零碎不归你管，速度也就那样了。耗时长还没法优化，这个问题又该怎么解决呢？
其实，你想一下，一笔转账既然被拆成两个操作，那这是不是也意味着，用户对咱们的期待也能拆成两个呢？第一，是账户的钱有没有缩小；第二，是钱什么时候到账。
既然如此，咱们能够先批改账户的余额，先把后果返回给用户这边，等一会儿再调用内部零碎也没问题。你看上面的代码：
class Account {
// 余额
private Integer balance;
// 转账
void transfer(Account target, Integer amt) {synchronized (Account.class) {
// 本零碎操作：批改余额，破费 0.01 秒
if (this.balance > amt) {
this.balance -= amt;
target.balance += amt;
}
// 调用内部零碎：转账，破费 5 秒，但会在后盾异步执行
ThreadPool.execute(() ->
payService.transfer(this, target, amt)
);
// 返回后果给用户
System.out.println("转账胜利，以后余额：" + this.balance);
}
}
}在这里，转账仍旧是一笔一笔地解决，但在调用内部零碎的时候，咱们开了一个异步线程。这样一来，转账速度就有种快了几百倍的感觉。
本来用户转账要等个 5 秒，但当初只须要 0.01 秒，就能看到余额的变动。正当用户诧异的时候，银行的短信也来了，速度竟然变得这么快，真的是太惊喜。
这样一来，主线程的执行工夫就被大大缩短了。
写在最初
在并发程序中，咱们会常常碰到饥饿问题，就是线程拿不到须要的资源，始终没法执行。
想要解决饥饿问题，咱们有三个思路，别离是：
- 保障资源短缺；
- 偏心地分配资源；
- 缩小线程的执行工夫；
咱们能够依照这三个思路，去剖析咱们的代码，缓解饥饿问题。
