LRU 变种啊，你是需要按时间删除和按最少访问删除。那么用 2 个链表。定时对超时部分删除。每次满的时候针对最少访问删除。

1.14 刚发布没多久时，看到别人发的［ Go1.14 以下版本 WaitGroup 一个奇怪的问题］。问题原因一样，很有意思。

我们公司就脱离了。netty 通信加 http 协议解析就好了。

数据库采用磁盘页作为树节点的方式，是内存资源，性能，数据持久化各方面平衡的实现方式。但这个开发起来非常麻烦。你去到 github 上找能持久化的树，要么是 mmap 方式限制非常大，要么是限制了 k,v 的数据或长度，或者是 leveldb 之类非常不稳定。leveldb 的定期合并整理在数据上来时会占用大量内存，与每个存储文件的大小有很大关系。这点我在拿 influxdb 的 tsm 存储引擎测试时验证。而 redis 之类主要只是内存存储，不符合持久化要求。因为业务需求，自己开发了一个，花费大量时间修复 bug 后才可用。仍然存在超长 value 后删除时，页不能完全回收的 bug 。外加事务支持也是很多其它存储不一定有的

根据产品定位和场景。能用 join 的话，我更相信没人会故意不用，开发效率上相差太多。不单需要处理更多的计算逻辑，大概率面临性能，资源，开发成本的平衡问题。不是不得已，不会脑抽干这个事情。数据库服务器承载压力总会有上限，不管你是多高端的机器。千万级的表进行大量 join 和复杂的计算，优化到很短就能出结果很常见。不用多，可以尝试下几十几百个同时进行试试会是什么结果。读写分离只能有限改善。只有做分布式，分库分表才有无限扩展的可能。但是这种做法直接导致了很多时候无法 join 。所以很多做法是根据业务场景设计库表，比如将同个用户的数据归到同个分片中，这样只访问该用户数据时可以 join 。无法 join 的时候设计方案处理。放心，总会碰到的

@axihe 做得好，完全能做到对开发人员透明。做在内网，使用内网 dns 。开发人员无需配置各种仓库等环境。

@axihe 从要干的活的角度来讲，确实没优势，要干的活没变。golang 包管理体验下来，优势是获取包只需要一个 http 下载和几个 http 接口。不用关心包管理工具自身协议和逻辑，二次定制化开发成本非常低。比如实现本地缓存仓库，内网环境代理服务，跨团代码仓库独立，跨团队包访问鉴权，无缝集成各种版本管理工具等。反证对它来说，只要通过 http 拿到，并且无篡改就好，中间经历了什么完全不在意。

我不是做前端的，deno 发布时粗浅的了解了下。关于包的问题，deno 目前只是提供的核心部分的功能，方向没什么问题。缺的是配套扩展的东西。它应该是借鉴了 golang 的方式。golang 在 1.11 版本中提供这种方式, 也就比 deno 目前状况好点。然后在 go1.13 基本已经解决了。你提到的这些问题除了[多版本共存]这个，可能需要像其他语言一样，提供条件选择编译或者选择性特性的等方式来处理。

1.写的服务都是部署在内部由你控制。但是由网关或者代理服务出去时不受你管理。你是无法控制他们的处理策略。nginx 默认样例就有对 50x 使用 50x.html 返回。多个团队合作时，会划分错误码。如果使用 httpstatuscode，无法应对团队扩展和业务扩展。
2.服务通信往往不是单单 http 协议。写一个接口，内部框架会转成各种内部 rpc 协议。http 协议进行通信仅仅只是一种。http 的 statuscode 可不是唯一标准。

@ayase252 这块应该有 checksum 设计。golang 就是，有 go.sum 。发现冲突，需要排查是包被篡改了，还是有人不按照规范来。

本地建 athens 之类的仓库存放第三方包。然后自己建 github，gitea 之类的作没内部项目的包。不过没外网，怎么取第三方包是问题

说白了就是尽可能提高资源利用率。性能要求已经超出一台机器所能承载的时候，不可能所有服务器围观一台数据库服务器干活。要么服务端处理这块逻辑，要么使用分布式数据库。

互联网企业对查询有要求。一个复杂的 SQL,一次查询占用大量 CPU 和 IO，即使查询速度足够，也会导致并发上不去。另外数据不均衡，有些大表需要分库分表时，连 JOIN 都没法自由使用。

@monsterxx03 分析对象没用才麻烦。已经逐步缩减范围了，发现接受请求才会触发。但是没能明确位置。触发后停止，然后执行 gc，对象都已经释放了。pprof 已经没有 inuse_object 了。但是有一项 inuse_space，显示的是汇编代码 CALL DI 时，systemstack 的占用。最后在往 go 程扩栈方向找问题时，不能再现了

@felix021 我也希望能复现。最小集已经在做了，只保留了描述中的几个 go 程。runtime.systemstack 和汇编的函数调用 CALL DI 的使用范围太广几乎没有帮助。因为 pprof 看不到占用的对象，去年后来是往调用函数时引起的 go 程扩栈方向去查的。同事开发中的代码，每天抽空排查的，可惜后来不能复现了

@felix021
刚才浏览器卡了下，竟然直接发出去了.
借地发一个类似的棘手的问题，至今没有找到答案。
内存随着运行不断增加。开始以为常见的泄漏问题，但并不是那么简单。
版本：go1.13.x 。去年的事 x 多少忘记了。
前提：window 下交叉编译成 linux 时会出现。 我的是 linux 系统，编译出来没问题。
调查情况: pprof 观察 inuse_space 能观测到内存占用，但是显示只有一条记录，是 runtime.systemstack 的占用，位置发生在 asm_amd64.s 的 370 位置。 功能是"call target function"，执行 CALL DI 。到这以为是调用函数栈的问题，检查程序后排除。 观察 go 程，仅 pprof 所使用的 go 程、一个 tcp 监听 go 程以及 main 程等待 signal 。
通过 linux 下的分析一些分析工具没找到头绪。根据可能性猜测去看了 runtime 源码也没能定位。

最后,不知道怎么回事，它好了。原本每次必现的问题，它竟然自己好了。然后就没法追查了。
不知道这里的各位有什么头绪