哈哈，如果只是短期内想知道招人时问什么面试题好，建议你把这个帖子换成 “各位 java leaders ，你们平时面试时会问什么问题”。

当然如果是笔试题，特别像是校招 /初级开发的，上网找找呗，比如：考核算法 /逻辑能力的，上 leedcode 挑些；考核语言水平 /数据库基础之类的可以去一些面试题网站，比如牛客网之类的找一些八股文；考核设计思想 /代码设计的，可以从语言内部或者生产环境实际应用场景中挑一些设计模式 /结构设计的题目；考核工程化 /架构设计 /基本运维经验的 /版本管理的....尽量依据自己的需求去设计 /问被面试者问题。

总之先确定自己对一个人业务能力的判断标准大概来自哪些地方，结合岗位需求，去设计相关的面试内容，同时你对于你要问的问题，最好每一个都有比较清晰且深刻的认知，知己知彼嘛。另外建议工龄低的着重问深度（深度+），工龄大的多问一些深度，也就是广度更大的深度（深度×n ）

如果你只是想快速得到较新的面试题库（包括答案）这些对于你应该有点帮助：
https://codetop.cc/home ；
https://github.com/Snailclimb/JavaGuide ；
https://github.com/DopplerHQ/awesome-interview-questions （关键词+github 去搜）
https://www.nowcoder.com/exam/company
....

搜一下都很多，如果不知道挑什么问题好，看看大公司招相同岗位问什么问题。

理解你的忧虑，但赞成#12 说的，与其说这是一个行业 /技术问题，还不如说这是一个市场 /投资问题，个人觉得主要问题是常规资本不会投向看不到收益的行业。

从宏观上讲，这不是一个兴趣大不大问题，而是搞了能不能赚钱的问题（投资者投了能不能赚到钱，开发者从事了能不能以此获得理想的工资），这种事情基本只能靠非盈利机构（比如高校 /研究院）或者 zf 主导投资来推动，但是 zf 主导的项目，不管做的怎么样，做的差的被各种诟病，做的好的可能得不到市场的信任，所以个人觉得，最合适的推动方式是 zf 出钱投资可靠性比较强的高校 /研究院，让他们立项去搞这些，把基建投资扩充到基础软件研究领域，国产基础软件发展是有必要的。

反对#14 楼 说的，虽然我也不赞同过于激进的思想，但看楼主发的内容也看不出过于民主主义的言辞，更多是对于当前国内开发的一种判断和忧虑，另外个人觉得以博爱之心去为人处世或做自己喜欢的事都没问题，但如果你发展技术所需要各种环境条件存在对你不够友好的直接或者间接障碍，你还保留博爱之心，是不是有点自欺欺人了。人活在这世上，为人做事都是围绕“我与世界”来互动的，“我”只能保证我是博爱的，但“世界”不一定是博爱的，个人的发展又离不开这个“世界”，所以选择一个对自己也博爱的“世界”对自己的发展是有必要的。就像现在中美之间的矛盾，假如某一天美国连最基本的个人电脑 /手机芯片都不让出口给我们，你还会觉得自己得保持博爱吗？

@hsymlg https://www.iso.org/standard/2229.html

rpc 只是个概念，feign,grpc,thrift 等你可以理解都是 RPC 的一个个实例，只是他们所支持的序列化方式 /通信协议，特性或功能，想达成的目的等可能不一样而已。

@dreamlike 你意思是语言层面要支持异步 io ，对吧？

@wuhaoecho 嗯嗯，不过个人感觉未来 non-blocking 数据库客户端将会是趋势，现在麻烦主要是，语言生态没有整体发力，就如 java ，最近版本才支持 virtual Thread,市面上又缺乏一整套从控制层到数据访问层的成熟框架，所以推广起来稍微麻烦，不过随着 reactive coding 的发展，未来大概率各个环节都趋向于 reactive 的风格。
@dreamlike 谢谢补充，话说你这里提的 runtime 是指 java 运行时吗？意思是通过重返 runtime 环境，使用 mounting /unmounted （虚拟线程） 来控制程序 blocking 的方式吗？

@litchinn 如果你想了解 r2dbc 可以看看我上面#16 楼发的那个链接，r2dbc 是 fully-reactive non-blocking 的
r2dbc 跟 jdbc 一样，只是一个数据库的客户端。
如果想了解 classic jdbc ，r2dbc 跟 virtual thread 的区别，你可以看看这位大佬说的,我觉得讲的很好。https://www.slideshare.net/juarezjunior/revolutionize-java-db-app-dev-with-reactive-streams-and-virtual-threadspdf
两者确实是不同维度的东西，个人觉得现有很多企业的生成环境业务都是使用传统的数据库（ mysql,postgresql 等），而 non-blocking connector 是为了解决这些传统方案的，另外不是每个企业都是随便就能用上分布式数据库的

@xxfye 嗯，确实，不过除了解决连接池占用线程资源外，我认为顺带还有一个提高吞吐量的衍生功能；
你说的 non-blocking 数据库这点即使有必要，但实施起来更加艰难，因为数据库厂商太多了，各家有各家的利益，当然开源的可能阻力稍微少点；
虚拟线程确实是个好东西，不过如果应用层语言是 java,生产环境中应用短时间可行性可能比较低，毕竟 jdk19 才支持虚拟线程，当然如果是其他语言，比如 go 的协程，可能好点，历史包袱没那么大。

@zeni123 哈哈，java 版“协程”是吧，确实 non-blocking 了，但这也意味着相关的框架和库也得跟进
@dreamlike 是的，RT 确实不是重点，正如我了解的一样，真正的异步非阻塞最好得是整套代码（比如 java web 项目从控制层到数据访问层）都使用 reactive 编程
@ychost 是的，你说的 r2dbc 确实我发这个帖子的原因，https://r2dbc.io/ 这好像是他们搞的一系列 reactive 库，感谢你告知我了 oracle 那段。
@yazinnnn 哈哈，有请课代表“协程”出场？
@liuxu 谢谢分享
PS:谢谢大家抽空回复

@hhjswf @billlee 谢谢回复，你们可能把主要问题集中在 I/O 延迟这方面了，当然 I/O 是延迟的主要原因，但根据科特尔定律高并发下一个程序的理想并发量（比如 VU ），除了跟响应时间（包括 I/O 延迟）有关，还跟吞吐量有关，两者都是影响理想并发量的指标，可能我表达不好，个人觉得 nio connector 的主要目的是为了解决后者的问题。

@MID 哦哦，我两步都没操作，所以怀疑是因为这个。但又搞不懂明明只是体验一下搜索引擎，为啥要搞这两个操作😂

我也一样，很早就在 waitlist 里了，就是不能使用，话说你们那个“Access the new Bing even faster” （ https://www.bing.com/new/fastaccess ）下的两个条件你们都完成了吗？没法体验是不是因为这两个操作没完成？

@vgbw 嗯嗯，不过个人觉得 Reactor 在有些接入层的应用是一个趋势，比如 spring webflux ，spring gateway 之类的。

@oxromantic 对，确实没关系，这里说的是数据库客户端 connector （就像 JDBC ）；虽然是内网，但是数据库大部分操作是 IO 密集型的，即使少了网络方面的开销，但个人觉得一次数据库操作的主要瓶颈还是在于磁盘 IO 吧；确实很多 connector 不支持 nio 模型，但不支持是因为没必要吗？ mariadb 确实有版本支持了。

@akira 可能不同的应用，不同的需求面临的高并发问题都不一样吧，不过个人觉得数据库瓶颈是很多高并发场景的瓶颈，而假如存在一个自带 NIO 的客户端去处理来自调用者的请求，还是能有效增加数据库操作吞吐量的。

PS:谢谢大家回复。

@liprais 哈哈，观点确实是来自别人的，只不过我觉得他说的有道理而已，但跟很多事情一样，自己觉得对的，不一定是正确的，所以才发贴问大家看法‘。另外个人觉得 non-blocking connector 想解决的是一个应用层的数据库连接吞吐量和伸缩性的问题，而不是一个数据库的消费速度问题，数据库的消费能力决定因素应该是其本身而不在于客户端连接工具上；跟比如 spring webflux 一样，相比 spring mvc 提高了请求吞吐量。
@liprais

有没有一种可能，存在一种比较中庸的方式：

1.相关性比较强的模块可以聚合到一个父模块下（比如你搞一个电商项目，订单中心，仓储中心，用户中心等横向服务，每个中心下的各个子模块整合到一个父模块下，也就是你上面说的方案一）

2.其他公用性 /独立性比较强的，抽出来做单独的模块（比如授权认证服务，日志服务，网关服务，监控服务，统计服务等纵向服务抽离出单独的模块，也就是你说的方案二）

3.如果你说的公共模块只是指代码层面的依赖，那么抽一个公用模块出来写公用代码没问题，不过它只是一个公用代码模块，而不是一个公用服务，凡是服务都是需要部署的，模块不一定要部署；如果它是其他业务服务依赖的公用服务，个人觉得能解耦的尽量解耦到具体业务中，不能解耦的说明其有独立性的必要，单独做一层服务，也就是我上面第一点说的横向服务，问题应该也不是很大。

@wangxin3 不给默认值，有时会出现一些使用上的问题，比如：某些函数像 sum,count 之类的有时失效，group by 聚合数据时有时也有问题，另外某些场景索引会失效。所以一般情况下都会给个默认值。当然以上纯属个人看法。

看看这个满足不满足你的需求： https://sipjs.com/guides/mobile/，不过内网穿透服务器是免不了的，而且这玩意如 3 楼所说，好不好取决于用户网络。
我记得腾讯云有这方面专门的服务（ https://cloud.tencent.com/document/product/647/32396 ），叫 TRTC ，不过是收费的，看你的需求。

@Nazz 哈哈，然而我只是一个小小的技术仔。我只是从过去别人的一些案例中总结到一点套路，不过说实话，营销确实有助于提高影响力，你看看这两天这论坛又有一个讨论度很高的“很焦虑，高中生”之类的帖子，先不讨论帖子本身，结合前段时间的 14 岁开源库的帖子可以看出，这类的话题就是很容易引起 v 友们的讨论，这也是我上面说的标签化文章和制造话题的作用。不过说个题外话，这也侧面说明这个社区逐渐成为有一部分人引流的地方，这不是我想看到的，但我觉大部分社区似乎都难以逃脱这个命运（就像以前的知乎），毕竟林子大了什么鸟都有。

再补充点建议：技术社区发帖如果有必要可以适当的采取我上面说的这类行为，但自己的博客和开源库就算了，除非你的“博客”不是一个单用户系统而是一个技术社区。