java 具体什么小版本？什么垃圾收集器？感觉这个现象很明显是 eden 区直接晋升老年代，老年代有空间但是需要进行内存整理（ full gc ）才能确保晋升，所以 CPU 一直很高的占用。当然只是可能，具体还要看环境、甚至代码。但是很少有应用需要新生代设置一半堆内存，你把-Xmn1g 去掉或者改小一点看一下。

typora 真的流畅，是我用过最流畅的 electron ，媲美原生应用了。作者真的用心打磨。

的确，redis zset 可以完成任务，但是想要考察的是数据结构和并发吧，参考 zset 的实现，hash + skiplist ，在 Java 对应的并发结构是 ConcurrentHashMap(url, pv)，ConcurrentSkipListMap(pv, set(url))。CHM 可以处理高并发读写，CSLM 处理实时排序（如果排序规则是最新的在最前面 set(url)换成 LinkedHashMap ），设计成事件驱动，在 url 被访问的时候加 hook 触发事件，然后面试官问问 CHM 原理之类就差不多了。 还可以优化，比如排行榜实时到什么程度？同一 pv 的 url 太多问题。排行榜既然叫排行榜，肯定不用全排行，一般都是一部分, 这就涉及 topN 问题。等等，能深挖的有很多。

@zhouxelf Sublime 4 默认配色是 Mariana ，感觉比 Monokai 舒服多了。
idea 的配色一般用 Darcula ，主要是其他配色在 idea 的色彩有问题，尤其是用了 Better Comments 、Grep Console 等插件高亮内容的时候。

那你看看 linux 之父怎么评价 C++的，你想转就转咯。你以为学了 C++就懂了 OS ，网络协议，数据库吗

在 V 站不是明知故问吗？ V 站食物链顶级语言 golang ，Java 在最底层，不如 Python 。据说 golang 简单，不倦，工资高。

@westoy 你去查一下 js 为什么叫 js ，js 的商标都是 sun 的，如果不是微软的垄断，今天浏览器运行的应该是 java 。当然还有乔帮主用 h5 杀了后来者 flash ，这都是后话了。这个世界从来都不是技术主导的世界。

kotlin 很多功能，java 高版本也有了。stream 惰性计算比 kotlin 增强集合其实更好，只是 api 可能没那么友好。感觉 kotlin 好用的语法糖也就闭包和扩展了，let ，apply ，with 这些高阶函数挺好用的。

@Chism 何不食肉糜？你知道开发 App 的成本多高吗？除了头部公司，谁还开发 App ？

NIO 也有阻塞模式，所以这里概念的确很杂。AIO 概念上就是非阻塞的，但是背压问题，linux 没有实现。

异步是异步（线程），阻塞是阻塞（ IO ，锁等），这两个不是一个概念的东西。异步可以阻塞，只是在 JS 里，没有阻塞的概念。我记得不错的话，Java11 的 HttpClient 依然使用的是阻塞 IO, 底层线程池是 ForkJoinPool.commonPool()，这个线程池只有 nCpu-1 个线程，适合做的是内存计算问题。而且是 Stream ，CompletableFuture ，CHM 所用到的线程池。所以 Java11 HttpClient 虽然 API 设计很好，其实在服务端生产价值有限。非阻塞的 HttpClient ，如 Spring WebFlux 的 WebClient ，一个线程发出几千个请求不是问题。

单线程没法实现异步。异步就相当于无限缓冲区的生产者消费者模式，所以才有流量控制，背压。这里面设计多线程，io ，网络协议问题太复杂。JS 的单线程异步，实际上是执行引擎的单线程，并不是没有 io 线程。
阻塞不阻塞是针对 IO 和网络协议的，OIO 是阻塞的，NIO （ epoll 、），AIO （ IOCP ）则不(全)是阻塞的。如果 httpclient 使用的 NIO ，则不会阻塞线程，一个线程可以创建几万连接都可以，一个连接也可以发出很多请求，但是 http 线头阻塞（ HOL ）问题，一个 HTTP 连接发出的请求要顺序返回，所以一般一个连接就发送一个请求，所以从协议看 http 是一个同步的协议。
netty 非阻塞就是 epoll 模型，epoll 通过线程的 loop （ selector 线程）来检查是否有 io 就绪事件。你现在这些困惑就是对这块系统知识不了解而已，你学一下多线程，netty 自然就能有答案了。而异步的 Servlet 让连接和处理的线程分开了，和这里并不是一个概念。
所有不在 Netty eventloop 线程处理 OIO （ JDBC ）当然就不会有阻塞。异步 Servlet 变得和 eventloop 有点相似，让连接和业务分开了，但是处理 OIO(JDBC)之类还是会阻塞业务线程的。
所以全链路异步基本很难实现的，现实是消费者速度永远更不上生产者，也不能有无限缓冲区，所以才有了线程池的拒绝策略。异步并不能提高处理速度，应该说其实降低了一点速度，但是提高了资源的利用率。

标准库 API 设计者比你懂，Java 标准库 API 不说是最好，也是所有语言前几的水平。真有问题的设计也有一套标准流程修改。你如果质疑，至少你需要达到他们水平，按照标准规则参与吧。不然和空想，民科有什么区别？

知其然，知其所以然。楼主还停留在使用阶段，建议楼主去了解一下 spring bean 的生命周期，BeanPostProcessor ，InstantiationAwareBeanPostProcessor 。核心生成 bean 的逻辑在 AbstractAutowireCapableBeanFactory.doCreateBean ，大致流程 createBeanInstance->populateBean->initializeBean ，createBeanInstance 就是实例化，populateBean 就是填充属性，set 和字段注入（@Value ，@Autowired..），initializeBean 就是初始化（ Aware, @PostConstruct ，InitializingBean..）。所以 initializeBean 阶段的回调都可以读取注入的值。

这不是 JPA 的问题，你换成 Mybatis 之类也会出现同样的情况。很明显是连接池的问题，Connection 一般都是有限的，你并发高，把 Connection 占完了，而且迟迟不释放。后面线程阻塞在获取 Connection ，你可以看一下你用的是什么 DataSource ，Hikari 默认只有 10 个连接。你把连接数调到几百试一下，你这就相当于慢查询，造成的雪崩效应。但是真实环境下 Connection 也不能太多，不然雪崩的就是数据库了，JDBC 的阻塞性其实保护的是数据库。

@bigbyto 你这种方法是错的，Java 类模型，子类或者类外无法访问祖类被重写方法。你这方法是 java7 某个版本的 bug ，在《深入理解 Java 虚拟机》里面也有你这例子，但是 R 大后来去问 JVM 相关开发者，确认这是 bug ，之后就修复了。修改字节码 invokevirtual 变成 invokespecial 也只是访问父类方法，也无法访问祖类方法。