这应该算是早期 LazyTraceThreadPoolTaskExecutor 的一个 bug 。
用最新版的 sleuth 能看到里边多了个 cache ，保存了 ThreadPoolTaskExecutor 和 LazyTraceThreadPoolTaskExecutor 的映射，用来保证同一个 ThreadPoolTaskExecutor 只生成一个 LazyTraceThreadPoolTaskExecutor 。

debug 了一下大概明白了。
spring 中注入的 ThreadPoolTaskExecutor 只有一个。但引入了 sleuth 后，它劫持了 executor 的调用。executor 注入 Example.class 后每次调用 executor 内的方法时，都会用这个 executor 包裹一层 LazyTraceThreadPoolTaskExecutor 生成一个新的 LazyTraceThreadPoolTaskExecutor 对象。

这个问题没啥讨论的，你担忧的问题早就被类似 HDFS 这种分布式文件存储系统给解决了。

一模一样的代码试了下：

1835794313
org.springframework.cloud.sleuth.instrument.async.LazyTraceThreadPoolTaskExecutor@549ac12c
1835794313
org.springframework.cloud.sleuth.instrument.async.LazyTraceThreadPoolTaskExecutor@549ac12c

不简单不明了，解释还是错的。

日经贴，会不会 stream 不能作为代码水平的判断工具，用 stream 写烂代码的人比比皆是。建议上 code 。

这个问题也算是面试常问问题之一了，稍微准备下最好。回怼什么的没啥意义。

你写了 a = null ，但 new A() 对象因为某种原因未被 GC ，这才叫内存泄露。
static 属性作为 GC root ，任何时候都不会被 GC 。

代码层面可能无法强制规范，是否可以建 version + id 的索引，强制 update 语句必须使用该索引，未用到该索引的语句在 SQL 层面直接报错。

“我理解是 Java 有 Spring 是因为它是纯面向对象的，没有函数这个概念只有方法，所以在一些需要函数的地方就需要通过 IoC 来注入一个单例。我作为使用者感觉到的是，IoC 是面向对象语言对于一些无状态的逻辑的妥协。”

个人这个认知不太准确，Java 的 IOC 框架 1 是为了解耦，2 是为了切面。单例对象是附赠功能。

不存在哪个语言应该是什么样子，语言最终会趋向于用户认为更好用的模样。

有时觉得程序员之间的认知差异真的是很大...容器化都已经成为标准了，还有这么多人认为容器是多此一举。

可能你用的是 ES 自动生成的 mapping ，没有自定义。无需分词的字符串字段改成 keyword 。

爬的，有后台。

@linuxsteam 不用 readLine 用 read 试一下，感觉 @AoEiuV020CN 应该是对的。

如果是缓冲区写满了，shell 脚本不变，把缓冲区改大点，还会阻塞吗？
问题应该出在 readLine ，readLine 没有读到 \r \n 会阻塞。这个方法使用时要慎之又慎。

其实吧，阿里和腾讯没做这些操作是因为他们已经有用户的这些信息了，这算...金融沉淀资产?

@xuanbg 怎么规避？请指教。

@zeyexe 他是把暂存区的搞没了。

@hanssx 很多时候就是这样，碰到不讲理的人，只能比他更不讲理。
我们搞技术的往往不善沟通，暗暗吃哑巴亏。op 你气不过的地方在于自己明明占理，但和对方的言辞交锋中占据下风。

这没什么解决办法，多交朋友，多和人沟通，时间长了自然学会阴阳怪气回怼了。