@ruixue #7 一、CDN 不能直接获取到明文，除非你让它获取。二、服务器记录日志不脱敏，是程序设计问题，并且在开发期就可用解决，那这个就不能用来作为运行期安全措施的论据。客户端加密或者 hash ，那是肯定有意义的，但是要不要实施这种措施，是要跟成本做对比的。当前，密码泄露的风险，真得没有客户端 hash 密码造成开发测试的不方便的成本大（服务器密文保存密码更多的是防止撞库，这也能解释为什么服务器不能只是单纯的 hash 密码，而必须先加盐再散列）。

@dLvsYgJ8fiP8TGYU 只有超高安全级别要求才会在客户端加密密码，通常都是：客户端和网络传输明文，服务器端存储散列码（密文），通过 HTTTPS 来保证网络传输阶段不被窃取。此外，就算你这个系统的安全级别是要求客户端加密密码，对于没法升级的旧系统，也得允许降级成客户端不加密的方式。

面向对象编程第一个解决的问题：让开发类库的人和使用类库的人可以分开。开发 Spring ，和使用 Spring 开发业务，一个是开发类库，一个是使用类库开发业务，你不能那一个标准去看源码。

你说的 2 ，其实就是 1 ，只不过是把解决冲突的操作从本地搬到远程而已。2 发生冲突的时候，你并不是必须用远程仓库的工具，还可以本地在 feture 解决冲突并推送之后，再重新执行 MR/PR 的合并。MR/PR 开启之后，是可以继续提交的。

如果你执行的是全 merge ，并没有 rebase 的话，2 会更省事点。

如果是用 rebase 来搞准线性历史的话，要用 1 的方式。

这问题的答案，不取决于技术或任何客观性的东西，完全取决于你的领导和公司的风格。要是“零 BUG”风格，你不管选哪个最后都要背锅。

正常情况下，都是问题越早发现越好的。CMMI 、ISO 体系（不是国内那种拿到资质就不再遵守的假体系），以及各大开源框架体系，选择的是前者，去看看开源框架的 Issue 库和版本发布文档就能看出来。

对于 JPA 、Hibernate ，或者任何 DDD 模型来说，所有关联对象都是要（立刻或者延迟）全部加载进内存的，所以不能随意设计关联，要在业务上的关联和性能上的伸缩性之间做平衡。

其他备注：不要太过于在意 N+1 问题，N+1 虽然是 N+1 次查询，但是实际上也就两次 SQL 编译，对性能影响不是严重的级别，能解决掉是好，但是为了开发便利性不解决也可用。

虽然都是基于 Java ，但面向前端 UI 的生态，跟面向后端的生态之间的区别，要比跨语言还大。kotlin 毕竟是从 Android 出发的，后端一时半会不会用。

还有另一方面，Java 太大了，Android 部分，和 Web 后端部分，只是最流行的（或者说搜索引擎上搜索最多的），但可能连 Java 总生态的 1/3 范围都没占到。（比如说，Mysql 数据库、Oracle 数据库中的 Java 部分、Hadoop 、Storm ，这些都是 Java 开发的，即没有用 kotlin 也没有用 spring 。）这直接导致除了基本 JDK ，很难有框架能一统天下。就是 JDK ，因为 JCP 基本上被 Oracle 独家控制了，也快分裂成 JDK-current 跟 JDK8 两套了。

@nevin47 #19 我建议你还是先去仔细区分下 CPU 架构 /指令集，操作系统，虚拟化，容器化的区别。

@nevin47 #10 不管是容器，还是分区，这都是在不改变 CPU 架构的情况下搞的。垮了 CPU 架构，因为指令集不同，必须要搞虚拟化或者指令模拟。跨架构虚拟化肯定损耗很大性能，指令模拟需要很大的投入成本，做得要不好还不如虚拟化。说个简单的例子，windows 下的 docker ，是要先用 hyper-v 搞个 linux 虚拟机的，这还只是跨系统没跨 CPU 架构。

POP3 确定没推送，IMAP 和 Exchange 貌似也没推送（ gmail 跟 outlook.com 貌似是用额外服务做得推送）。电脑上的传统邮箱客户端都是定时拉取邮件的。IOS 系统没有单项服务的后台，你得想其他办法了

别的不知道，但是如果不一样的话，你不管是上 docker 还是上虚拟机都没用，跨架构的虚拟化，性能损耗非常大。

这应该是 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 不合理，所以肯定要有啥东西来做干涉，这事前面的人回复的更好。