@liuhan907 @lmshl 异步跟单线程不冲突，用线程池处理异步是 Java 的专用方式，其他语言处理异步不是用的线程池。

@lmshl 客户端应用读取一个文件准备编辑，说直白点就是记事本，这你也要用 NIO 去读取文件吗。虽然 Java 桌面应用很拉跨，但你也不能假定 Java 就只是搞 Web 服务器或者大型计算的，有些场景就是简简单单的线性同步处理，这时候你用 NIO 那就是杀鸡用牛刀。

@jeesk 同步异步这里我草率了，NIO 是确实是同步非阻塞的。NIO 跟 BIO 区别的是任务切换的效率，跟同步异步没多大关系，BIO 也能做异步。他俩用哪个，主要还得看并发。

发现楼上有些人是 “nio 优于 bio”，或者 “nio 要替代 bio” 的想法，这是不正确的。NIO 异步非阻塞，BIO 同步阻塞，这俩是应对不同场景的，不是不考虑场景就无脑用一个。如果是客户端应用读取一个文件准备编辑的场景，用 NIO 就是个沙雕（这里 UI 那里可以将读取文件的过程作为子过程异步调用，但读取文件这个过程，单线程阻塞是最优解）。

还有异步同步也是要分场景的，并且异步本身，也是分为全异步的 callback 模式跟异步同步结合的 async/await 模式。无脑异步，或者无脑 callback ，也是沙雕行为。

楼主是上面看法的反方，是错的，但不代表上面看法的正方就是对的。楼主的标题说的是很正确的，互联网上的很多知识都会带入非黑即白的世界观，这才是最大的误导。

还有，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 站。