很多人都想要应用的内存更少，响应更快，并发更高。想要单位服务器内，能部署更多的应用。

这需要多个方面的努力（就像接力赛）：

### 指导原则

* 加载的包要小（越小，基础内存占用越少）
* 处理过程产生的上下文数据要少（越少，单位时间内的内存越少。相同并发量，内存相对更少）
* 响应速度要快（越快，上下文数据在内存里呆的时间越少。相同内存，支持更大并发量）


### 起跑棒

使用 solon 能让内存节省 50% 左右，且在框架层面并发高 700%。这是一个很好的底子！

* 一般来讲。开发时多注意些，开发完后都是能保持节省 50% 左右的水准。

### 第二棒（靠架构师的选择）

选择较小的、省内存、响应快的第三方框架。选择合适的、克制的、有成效的。

* 比如，HikariCP 会小些
* 比如，HikariCP 4.x 比 5.x 会小些
* 比如，mysql-connector 5.x 会比 8.x 小些
* 比如：okhttp 3.x 比 4.x 会小些
* 比如：redisx(jedis) 比 redisson 会小些

能合并的则合并，同类型的不要重复引入多套：

* 比如，用了 hutool 就尽量不加 apache common
* 比如，用了 hutool-http 就尽量不加 okhttp
* 比如，用了 fastjson2 就尽量不加 jackjson, gson, 等同类框架

话又说回来，小和快不是唯二原则。还有安全等等...（合适，才是最重要）。


### 第三棒（靠程序员写）

开发时，节省内存（原则上，产生的上下文数据越少越好）

* 比如，不断的创建连接池（内容就会不断涨，直到挂掉）
* 比如，文件流读到内存（比较吃内存）。多次读，或转码，或分析，都很费内存
* 比如，分布式网关要用流式转发（滞留数据会比较少）
* 比如，SQL 很慢，响应能力会很差，且很吃内存

开发完后。用压测试具试一下效果。观测下内存波动和并发情况。

### 最后棒（看运行）

在相同请求量下，上下文数据的内存占用越少（单次内存少），响应越快（占用时间少），越省内存。

* 可以考虑合理的缓存
* 如果，并发请求量非常大，要考虑集群