nio ，你想开多少都可以，还不用担心线程太多。不过你调用的三方服务也是够垃的。

推荐惠普战 x：

优点：
13 14 15 存可选
amd intel 版本可选
内存能升级到 64g
hdmi2.0
扩展接口齐全，不用携带扩展坞
同时支持 typec 充电+圆孔充电，十分方便
键盘手感好，支持背光
薯条标好看

建议：
那些 16g 内存焊死的千万别买，16g 内存真心不够
还有那些 hdmi1.4 的也别买

毕竟大多数项目的耗时大头都在数据库层面，使用堵塞 io 只是比 nio 多占几十个个线程，还不至于影响到问题的核心。
我曾将公司项目从 apache httpclient 改为 webclient ，从压测上看对 tps 提升十分有限。因为 tps 上升之后下游服务瓶颈在数据库，导致堵塞本服务，所以本服务是否用 nio 都不会对 tps 带来本质提升。

但却带来挺多坏处，比如偶尔发生的 io 异常，连接中断之类的。使用 apache httpclient 后再也没有遇到这种情况。

还有就是堵塞式的天生是线程隔离的，输出日志携带 mdc 查日志要方便很多。

除非你的项目中 http 占用大量资源，否则不如用老牌 apache httpclient 想要 nio 可以用 apache async client 。不推荐用，

a 线程使用赋值语句赋值后，b 线程可能看不到

写代码时，尽量保证数据库兼容性。
如加字段这种可以兼容的改动，失败代码回滚后不影响。
如修改字段，删除字段这种改动，可分多次代码迭代实现，如增加字段取代旧的，然后再删除旧的。

试了一下 使用 springboot 似乎么有问题

拿当初 spring1 的代码放到现在 spring5 里面，仍然兼容。
这不正是说明设计的很棒吗

第二种方式没问题，resilience4j 中就有与这种做法类似的做法

@nothingistrue 你发散的太多了，题目问的是 为什么 MyRun 里面设置了中断后，查询中断状态为 true ，MyRun2 中是同一个线程，再查询中断状态却为 false 。

答案是：在线程池的 getTask 方法里，调用 BlockQueue 的 take 方法，抛中断异常后中断状态被清除了，所以 MyRun2 中获取到中断状态为 false 。

@nothingistrue 不管怎么理解注释的描述，在 java.util.concurrent.LinkedBlockingQueue#take 方法里。第五行
调用 takeLock.lockInterruptibly();
点进去
```
public void lockInterruptibly() throws InterruptedException {
sync.acquireInterruptibly(1);
}

public final void acquireInterruptibly(int arg)
throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
if (!tryAcquire(arg))
doAcquireInterruptibly(arg);
}

```

可以清楚的看到，会主动检测并清除当前线程的中断标识，如果为中断状态，清除并抛出 InterruptedException 。
主动检测线程的中断标志位，是毫无疑问的。

@litchinn
@nothingistrue

自答一下：

首先我们要知道，如果我顺序的执行以下代码，是会抛出中断异常的
```
BlockingQueue<Runnable> queue = getQueue();
Thread.currentThread().interrupt();
queue.take(); //这里抛出中断异常
```
虽然是先设置的中断状态，后执行的堵塞队列的 take()方法，但 take()方法内部会检测当前线程的中断状态。



那单线程池是如何工作的呢？可以认为一个堵塞队列，加一个死循环的线程。线程从队列中获取任务执行，而这个获取的过程就是调用了
BlockQueue 的 take 方法。

所以这就解释了题目的问题，
1. 我们在 MyRun 中将当前线程设为中断状态，MyRun 执行完成后线程处于中断状态。
2. 然后开始从队列中 take 下一个任务，此时就会抛出中断异常，并清除中断状态
3. 线程池抓住中断异常，忽略并继续 take 下一个任务
4. 此时 take 到 MyRun2 任务，并执行它。这样 MyRun2 再检测中断状态就是 false 了


总结就是，线程池在 take 下一个任务时，如果抛出中断异常，会抓住异常并继续 take 下一个任务，而抛出中断异常时中断状态就被清除了。


这一快的源码如下， 正式在 while 循环的条件里，一直调用 getTask() 方法，
```
final void runWorker(Worker w) {
Thread wt = Thread.currentThread();
Runnable task = w.firstTask;
w.firstTask = null;
w.unlock(); // allow interrupts
boolean completedAbruptly = true;
try {
while (task != null || (task = getTask()) != null) {
w.lock();
// If pool is stopping, ensure thread is interrupted;

```

getTask 方法，正是调用了堵塞队列的 take 方法，并忽略了中断异常
```
private Runnable getTask() {
for (;;) {
try {
Runnable r = timed ?
workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) :
workQueue.take();
if (r != null)
return r;
timedOut = true;
} catch (InterruptedException retry) {
timedOut = false;
}
}
}
```

@qfdk 这个好像不能看出线程的中断状态

@cheng6563
@uSy62nMkdH
因为是个单线程的线程池，Myrun 和 Myrun2 其实用的是同一个线程。通过输出的 thread hashcode()也能看出线程是同一个。

Myrun 里面已经将线程设为中断状态了，理论上 Myrun2 运行的时候应该是处于中断状态的，但是却没有。所以一定有一个地方将该线程的状态标识移除了，我没找到在哪里实现的。

@wellsc 与哪个版本的 redis 没有关系，因为应用与 redis 网络交互 RTT 的存在，单线程写很难达到 1000 次 /s 。

你只能做到 redis 与 db 中的某个瞬间的数据是一致的，不可能保证恰好与导入完成时数据一致。考虑看业务上能否改。
另外 redis 写时，开 20-30 线程一起写会快很多。

h2 可以设置磁盘模式。
本人觉得可以用在生产上