这应该是 Linux 基金会的组织成员邮箱，不是普通个人邮箱，一年 99 刀已经算便宜了。问题还不在于一年 99 刀，而在于你要不是贡献者的话，用这个邮箱那就是个用钱搞来的名誉 Linux 基金会成员，让人笑话。

回头看了下，我上面 #10 这段回复（ Run1 后面的代码不会清除中断状态，如果没有其他东西干涉，这俩 isInterrupted 要都是 true 。但是上面的情况对 Run2 不合理，所以肯定要有啥东西来做干涉，这事前面的人回复的更好。）是错的。纠正一下：

Run1 后面的代码 不会清除中断状态，这实际上是会造成问题的，应该有代码手动清除（这也是当前线程调用 Thread.interrupt 在高安全策略中不被允许的一个原因）。Run1 到 Run2 之间会经过一些列的其他系统代码，这些代码只要发现中断状态就会清除它（若不清理就违反了设计理念，是 BUG ）。

@git00ll #17 请仔细看看 ThreadPoolExecutor.getTask()的 Javadoc 源码，它的作用是获取任务，不是清除中断状态，而是在获取过程中如果被中断了就自动恢复。

try {
Runnable r = timed ?
workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) :
workQueue.take();
if (r != null){
return r;
}
timedOut = true;
} catch (InterruptedException retry) {
timedOut = false;
}
这段代码(为了便于理解我给格式化了)，结合“它在死循环中”、“有其他代码片段会使用 timeOut 这个变量”这两点后，它的作用是：

一、当 timed =true 时，在指定的时间内从队列获取开头元素，直到获取到、超时、或者被中断，若获取到则跳出死循环执行方法返回，若超时则设置 timeOut=true 然后`continue 死循环`，若被中断则设置 timeOut=false 然后`continue 死循环`；

二、当 timed=false 时，无限期从队列获取开头元素，直到获取到或者被中断，若获取到则跳出死循环执行方法返回，若是被中断则`continue 死循环`；

无论哪种场景，被中断时，选择的处理都是继续循环，相当于若被中断则自动恢复。


这里真正解释的是：为什么线程已经被标记中断了，Run2 还能被执行。

至于你的问题，线程是何时清理中断状态的，这个问题的答案是：只要开始执行下一行代码了，它就清除中断状态了。这是一个设计理念。按照 Java 中这个 interrupted 的设计原理，当处于阻塞（等待）状态的线程，执行任何其他代码前，就得先清除中断状态，因为它只要执行了其他代码就是响应了中断信号，它就不再是“刚刚收到中断信号”的状态了。你现在是正好找到了这一处代码，但它是设计理念的果，不是因。

线程的阻塞状态，Java 线程类的 interrupted 属性 /状态，这是两码事。

另外异步任务执行调度跟线程调度也不是一码事，只有 Java 是用线程池做异步任务的，其他语言用得不是线程池。

今天太晚了，先这样吧

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;
}
}
}

这段代码的意思，不是忽略中断异常，它的处理跟主处理是不一样的，timedOut 一个设定为 true ，一个设定为 false 。这个是响应了 InterruptedException ，不是忽略了它。或者说，它响应了中断信号。

看了一下，不管是 lock.lockInterruptibly ，还是 condition.await ，都会在线程已经处于 interrupt 的时候抛出 InterruptedException 。但是这里的意思可能是：不允许线程不处理中断信号就走向或返回到阻塞状态。线程收到中断信号以后，可以啥也不干，但必须解除“收到中断信号”状态，类似你可以啥也不干，但必须告诉系统已经收到了。

你必须意识到这一点，这个先中断后 take 抛出的异常，不是 take 方法想抛的，而是内部的加锁或 await 机制跑出来的。你这个异常的根源是 Thread.currentThread().interrupt();这一句，跟 take 原本的意愿没有关系。

@git00ll #11 你先看一下 BlockingQueue.take()的 Javadoc ，你这里第一条就理解错了，后面的就没法再看了。

BlockingQueue.take()
Retrieves and removes the head of this queue, waiting if necessary until an element becomes available.
获取并删除队列开头元素，否则在新元素可用前一直等待
Throws: InterruptedException - if interrupted while waiting 。
当等待中被中断时，抛出 InterruptedException


该方法的原理是：如果队列为空，则等待（此时线程处于 WAITING 状态，该状态时一种特殊的 BLOCKED,可以认为就是 BLOCKED,即线程阻塞），如果被（线程调度机制）唤醒，则获取并移除队列的开头元素，如果等待过程中被中断，则抛出 InterruptedException 。

请注意：InterruptedException 是受检异常，是被捕获后应当自动纠错的异常。它的作用是告诉你线程在阻塞状态时收到了中断信号，它的意图是让你接触阻塞状态然后释放资源（当然这只是个意图，干不干取决于你，你完全可以不例会这个信号重新恢复到阻塞状态）。

先回复一下，我先去看看 BlockingQueue.take()的源代码再说。

有容器建议合并吗？
数据不拆分则服务不拆分，Backend 与 Admin 要合并。

用户登录有没必要单独再分个 Auth 容器出来？
现在不要，将来的事看将来的情况。

如果部署在同一台服务器上，容器间通信有没有必要上 HTTPS ？如果部署在不同服务器用云厂商内网呢？
不管你是部署在同一台，还是不同台，都要把它当成部署在不同的地方看，这样才省事。纯内网没必要上 HTTPS ，当然你要愿意折腾可以一部到位，但这个真不好折腾。

关于你那个 Backend 、Admin 、Auth 的拆分问题。首先要看业务界限，简单来说就是数据库上能不能独立出来，数据不独立就一定没法拆。其次要看你的实际伸缩性要求了，伸缩性要求不高的话，那怕三个都是超高度内聚的，都可以放到一个服务里面。

Run1 后面的代码不会清除中断状态，如果没有其他东西干涉，这俩 isInterrupted 要都是 true 。但是上面的情况对 Run2 不合理，所以肯定要有啥东西来做干涉，这事前面的人回复的更好。

isInterrupted 表示的不是线程是否中断（阻塞），而是该线程是否刚收到其他线程给他的中断信号。你这里只有一个线程，没有线程之间的通信，所以 isInterrupted 应该恒定返回 false 。不过，你的 Run1 自己给自己了一个中断信号，导致 isInterrupted = true 。

interrupt()这个方法（注意还有一个 interrupted 方法，这俩不一样）的实际作用是给目标线程一个“请你中断”的信号，并不是中断目标线程，目标线程做啥反应，是由目标线程自身决定的。Thread.currentThread().interrupt()，这样自己给自己中断信号，是一个很怪的操作。

lombok 省事，但是这个是语法糖不是代码模板，用起来有争议。

可以考虑用包装方法把 checked exception 变成 unchecked exception 。例如：
writeValueAsStringNonChecked(ObjectMapper mapper, Object object){
try {
mapper.writeValueAsString(object);
}catch(JsonProcessingException e){
throw new RuntimeException(e);// 用得多了还可以考虑定义一个专用异常
}
}
这个方法放在哪里很自由，看你的工程规范。

加点钱，上去年、前年、甚至大前年的旗舰级，旗舰翻新机也可以。其他牌子我不清楚，我主力机用得是三星前一年的旗舰级，用了 2 年除了系统换港版外没任何不适。

单纯备用机的话，还可以考虑二手 Iphone ，这个我用了 4 年了。

前提是你要准备拿外包当跳板进编制，哪怕是要当 10 年以上的跳板。外包最大的问题不是当前如何，而是以后如何。要是你那这种外包当常态，那你就是那种一有风吹草动就被优化掉或者顶上去的临时工。

[ERROR] Plugin org.apache.maven.plugins:maven-clean-plugin:2.5 or one of its dependencies could not be resolved: Failure to find org.apache.maven.plugins:maven-clean-plugin:jar:2.5 in ~~~~~maven.aliyun~~~~/nexus/content/groups/public/ was cached in the local repository, resolution will not be reattempted until the update interval of alimaven has elapsed or updates are forced -> [Help 1]

这就是阿里 Maven 镜像干得好事，org.apache.maven.plugins:maven-clean-plugin:2.5，这个包它竟然没有。

阿里 Maven 不是官方镜像，而是 jcenter 的镜像，貌似还有魔改，经常出问题。网易你家的已不能访问，现在老难受。

所有链接都是 http，不是 https。