还有，NIO 200 个线程是应对五万并发连接的（一个 Linux 单机最高就能开这么多连接，没这个限制它能应对更多），实际上压根也用不到 200 个线程，物联网或者没有文件上传下载场景的接口服务器场景下，10 个线程就能轻松应对五万并发连接。请注意这里的并发连接是指可以毫秒级别同时响应的连接。

后面你提到 RPC 大多用 NETTY ，那是因为 RPC 服务器是至少上千通常上万的并发量（没到这个并发量也没必要开 RPC ）。

你的标题是对的，但你下面说得谬论好些不是谬论。

1. 抛开剂量来说影响，那是耍流氓，线程切换的消耗跟线程的数量，是指数对比，200 个线程你看不出来区别，但是一千一万呢，不要说物联网服务器，就是面向公众的普通 Web 服务，那都是一万起步的。

2. 请参见一，在 tomcat 改成 NIO 之前，它要么只应用在不到百人的企业内部，要么躲在 IIS/Apache 后面，压根不会直接面向公众（早期确实有不负责任的人那 tomcat 当前台服务器的页游，那响应速度是相当感人的）。

3. 这么貌似确实是谬论，我也没看懂。Netty 本质上只是对 Java nio 的易用性封装，并没有动 NIO 的原理。至于你的阻塞疑问，IO ，不管是本地 IO 还是网络 IO ，并不是总是在传输的，他经常是在等待输入源 /输出目的可用的等待过程，这期间它是不工作的，这个时候，如果是 BIO ，不管是否工作它都要占用线程，如果是 NIO ，不工作期间是不占用线程的。

IOS 、Andorid 、TypeScript 、C#/Xamain/WinForm ，这几个是平滑切换的，切换起来基本只需要转换细节性的习惯,不过前提是至少吃透了 1 个。你只有 1 年经验，IOS 很难吃透，这样没有转换的可能性，基本都是重来，所以不到万不得已或者确实不想搞 IOS 了，不要转。

如果是向往 Java 后端走，那就跨行了，这个没啥固定评价，主要靠你面试之后自我评估。

正常途径下，没有。亮屏设置当中，前台应用的设置具有最高优先级。系统不会打扰前台应用的亮屏设置，更不会允许外部应用干扰当前应用的亮屏设置。

正常途径，也好解决，向 APP 反馈让可以自定义亮屏设置。这个改动不难，如果不改，那就是流氓应用，卸载对待。

旁观者轻：#XXXXX#替换为 aXXXXXa ，跟#替换成 a ，没有区别。

实际寿命通常是售后期限的两倍，智能手机售后都是一年。一般两年以后的大版本更新，基本上仅取决于自动测试的结果，那是绝对不会专门安排人去负责更新的。苹果能更新好几年，那是因为 IOS 系统基本不大动——光 UI 风格都能好几个大版本一样就更别提底层引擎了。三棒能升级三年，那也是因为 Android 现在的系统本质上都是 8.X 。（当然总归是要变一些的，所以那些老手机升级后，因为只经过自动测试没经过人工调配，大概率要变差。）

还是见得少，Oracle 的一部分、Mysql/MariaDB 、Handop 体系、Apache Storm 等等工具类的应用，这些也是 Java 开发的，他们不用 Spring 。只能说业务类或信息处理类的应用（以前还有专有名词 Java EE——Java 企业级应用），绝大部分都是用 Spring 体系的。

@codergrowing #15 可能我记错了，不过 Spring Boot 之后，Spring MVC 部分推荐的都是通过方法参数注入，已经基本不用成员变量注入了，这种注入单例非单例都没区别。一般来说，从 Struts2 之后，控制器部分都是单例的，可能 Spring MVC 发现没有成员变量注入之后会自动优化成单例模式。

你的第二次使用已经正确了：注入到 Controller ，再传递给 Service 。Controller 是非单例的有状态 Bean ，可以注入 HttpServletResponse 。 @twofox

其实对于 HttpServletResponse 这种跟当前请求绑定的对象，最好全程通过方法参数注入，不要将他注入到类的成员变量上。Spring MVC 中，如果把 HttpServletResponse 作为 Controller 的方法的参数，不需要加 Autowired 它都是自动注入的。

HttpServletResponse 是绑定当前连接的有状态对象，Service 通常是无状态 Bean ，Controller 通常是（ Spring MVC 就绝对是）有状态 Bean ，因此，HttpServletResponse 注入 Controller （的成员）没问题，注入 Service （的成员）会产生严重问题。

你如果注入 Service ，那么第一个请求来了会把当前请求的 HttpServletResponse 注入单例的 Service 。单例的 Service 中的这个成员，一旦注入过就不会再重新注入了，以后所有的请求调用的 Service ，使用的都是第一个请求的 HttpServletResponse 。这个 HttpServletResponse 对象本身因为还被引用着不会被回收，但它里面引用的其他对象，会在第一个请求完成之后就销毁，于是后面就会出现 NullPointException 。


最后说一点，exportSevice.export(params, response) 这样的方法，即把依赖对象通过方法参数传入，不是用 Spring 实现的依赖注入，但它也是依赖注入。

@Kawa 你对跨平台（或者操作系统适配）、UWP （通用应用）、客户端的理解都有偏差，然而最直接的还是太迷信 go 。go 最开始以及现在一直是用来替代 C 的，也许还能替代 C++，这意味着它跟 C/C++一样主要是用来适配 Windows 、Linux 、Unix 等传统操作系统的，不适配 IOS 、Android 、WebOS 、Win10 mobile 这样的新型移动操作系统（并不是不能适配，而是生态不在这里很少有人去吃力不讨好的搞底层适配库）。

win10 mobile 跟 win10 只是内核一样，整体上还是俩类型的操作系统。kindle 和早期 Android 系统，你解锁了之后就是个 Linux 。

其实你有更好的方案：PWA 。然后你就会发现真正的难点是跟 QQ 服务器做沟通——理论上来说，任何接入 QQ 服务器的第三方，都要被南山法院锤。

@Ds97 #19 国外手机号上 Google Recaptcha 或者其他机器人识别，国内手机号用他说的微信那个方法。

逐步骤监控变量的值还有办法，但是你想在值变化时做自动处理（打印些信息），你不动代码是不行的。这是个 public 成员，可以直接赋值，切面都加不上。

还是想办法做断点调试吧，一步一步的查看值的变化。当然你不能直接在线上搞远程调试，尤其是你还想长时间的监控。你这个是公共静态变量，一个断点暂停就可能让整个系统崩溃。能在本地环境复现问题然后在本地断点调试是最好的，如果不能或者不好复现，那么只能逐行看代码了。

Eclipse 有几个功能可以帮助你找到哪个代码会修改这个值：右键变量然后选择“call hierarchy”；选中变量再 Ctrl+H ，然后可以查找所有引用这个变量的地方。

UWP 的基准就是 C#+Xamarin ，你这一不想用 C#二想绕过 Xamarin 直接启 exe ，那搞出来的只能是 Win32 转制 UWP （只能在 PC 端使用的假 UPW ）。

漏洞是漏洞，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 就够了，哈希都不要做。