漏洞是漏洞，BUG 是 BUG ，这俩本来就不一样。

此外 Spring 的跟踪系统，不管是以前的 JIRA 还是现在的 Github ISSUE ，都是跟踪 ISSUE 而非 BUG ，这本是就是不把 BUG 当负面性的跟踪系统。“零 BUG”是部分国人的专属态度，不管是 ISO ，还是 CMMI ，还是纯敏捷，都不要求这个态度。

终审会员，要么等于没用，要么等于要跑路，这事放到哪里都一样，最著名的就是 P 站。

说点题外话，好得产品经理，应该引导客户把沙雕需求变成好需求。如楼主的需求，对于客户来说，PAD/PC/MAC/WEB 编辑查看+手机仅查看，是比手机啥都干，更好的工作方式。如果实在要手机也编辑，那么花钱买个好的引擎，是比让上层 APP 做优化，更有效的实现方式。

Stream 及 Lambda 表达式的第一优点就是代码简洁，这跟 code review 是正相关，不是互斥的。

不过 Lambda 表达式能无缝转接，Stream 不能。Stream 使用的是数据流逻辑，跟传统的“判断、循环……”逻辑有区别，转换过去需要学习。但是这个学习成本不大，而且如果是数据结构 /算法已经很溜的，早就回了压根不用学。大佬刚开始不让用，可能还是要考虑团队管理，大佬要是一直不让用，那他 100%是假大佬。

@ruixue 我接着看了你后面的对话，发现你是一种啥都往最好做的想法，俗称“烂好人”。这个想法在事情小的时候是真好人。但是，哪怕是非常小的成本，也是会富集的，当事情大的时候，啥都想做好就会变成啥都做不好，成了烂好人。客户端哈希或者加密对于小系统（或者个人）来说确实成本很微小，但是对于几十甚至几百人开发的大系统，成本富集到管理者那里就会很庞大。这个时候管理者就要做均衡了，极为重要的系统不止要做客户端密码哈希，客户端非对称加密都要上，甚至可能还要上物理证书（俗称的加密狗），但是面向大众用户的客户端，上个 HTTPS 就够了，哈希都不要做。

现在 Spring Boot 也是滚动更新，J9 以上也是滚动更新。凡是滚动更新，不出漏洞才不正常。当然，对于 Spring Boot ，以及所有库，的滚动更新，如果你写好写全了单元测试代码（相比于只编码，工作量最少加两倍），那你只要一直用最新稳定版本就没事了，漏洞顺手就改，连手动测试都不需要。以上仅限于上层应用框架，JKD 这种底层基础设施，能不升级就别升级，尤其是 J9 以后那狗日的不考虑向后兼容性的滚动升级。

@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 的设计原理，当处于阻塞（等待）状态的线程，执行任何其他代码前，就得先清除中断状态，因为它只要执行了其他代码就是响应了中断信号，它就不再是“刚刚收到中断信号”的状态了。你现在是正好找到了这一处代码，但它是设计理念的果，不是因。