这么多信息，S 在其中……感觉是出题的干扰选择项嘛

A 和 B 的通信是否安全，现在就归结于拿到了 K 的 C 怎么使用 K 了

如假设：
1 、B 没有告诉 C ，有 S 的存在，C 通过自身能力、也无法获知 C 的存在与对应调用方法，粗且可以认为 A-B 是安全。
2 、B 告诉了 C ，有 S 的存在，但一般来说，S 对于 B 的交互注册，有名为 KS 的 key 存在，对 KS 尽管 B 喝醉了、B 没有 C ，那么粗且可以认为 A-B 安全

另外，以上假设是从 B 对 C 的情况已经透明可知的情况，如果对于 B 并没有把喝醉这件事情记起来、更没有告诉 A 。那么从 A 视角来看，还有 A 认为 A-B 间是否安全的问题。

从严格的安全角度来看，既然 K 已经泄露了，第一时间更换 K ，是比做上述各种假设更为安全的选择。

jvm 总体不要设过容器一半。各种 gc 相关参数打开、oom 时就能产生 heapdump ，拿出来分析内存溢出/泄露对象

还有：@imyasON

不要 不要 不要 随便随便就设置等同的 xms 和 xmx 。当堆内用量情况很平稳没有升代、长时间不需要 fullgc ，没有 fullgc 就有不能触发挂载在 finalizer 上的资源回收，可能导致包括堆外溢出等各种各样的资源耗尽问题。在确认没有堆外资源、没有 finalizer 依赖等等情况下，已经做过深度优化的基础上再考虑 xms=xmx 的设定。

Windows 默认输入法 bug ，要选择使用兼容性老版本

健康又卫生不得不尝

https://www.zhihu.com/question/389219452

洋垃圾准系统一套 200~300 ；+30 、40 一张千兆网卡
足够了，真讲划算比混这个再说吧

@mengzhuo 这正是用各类 loader 工具而不用自己代码程序的好处，各类 loader 工具和程序 sql 的差异了解下？

@hzjseasea 因为稍微正经点的数据库，都会有在 shell 下能够直接用起来的，配套文本导入工具/命令行功能。Oracle 的 sqlldr ； MySQL 的 LOAD DATA ； PG 的 COPY FROM 等等。原生直接对接数据库，速度快，不用再研发。数据库运维掌握这些工具是必备技能，出了啥问题也是运维和数据库公司支持方面搞定。（其实多少也是为了研发可以推点活到运维吧）

@jptx 恩，这就是比老老实实手动编码的思路，更老老实实的思路了。确实有道理，展示层进出的时候就弄掉，中间一路干净也是是正道。

能发送返回 http 就是浏览器

能解析 html 就是浏览器

能 render 页面就是浏览器

能执行 js 等动态脚本才是浏览器

来画个九宫格？

@NessajCN 后端要交出这块数据处理调用给到二次开发手里的，既然是二次开发，就要选择最没有依赖、人人都能用起来的语言环境=>我选择 shell 作为首先要支持的语言环境、或者由二次开发选择通过 shell 再调用他们自己研发的语言代码的入口。

@NessajCN 还有略的部分，看来这个要处理的内容还是会比较多的。利用 linux 命令和现有 sqlloader 工具就能实现的，差不多几行脚本和工具调用命令，就能实现的话；个人还是感觉不大会有二次开发人员，去首选自己开发这些代码了。何况相比 shell ，还有多个 nodejs 环境基础依赖。nodejs 较 shell 来说，不是通用入口的优选。

@NessajCN 求教了，如果我要用 fs 做一个：

1 、显示类似 sed 去掉数据文件行末和文末空格空行；

2 、在完成步骤 1 后，实现类似 sqlloader 工具，将处理后文件导入指定数据库。

这个应该如何做到呢？

@NessajCN 大概确实是我需求部分表达有问题了。服务器端调用 sed 、sqploader 、或其他自有工具等形式，对数据的文本清洗处理等后再加载。其中用 shell 作者为先后处理/加载的过程的总入口，我理解是最通用的一种文件上传处理框架中，需支持的入口模式了。我不能理解，fs 能够作为数据文件清洗/处理/加载的总入口吗？

@mengzhuo 可能是我表达不清？ txt 文件上传后，服务器端自动触发开发编写的 shell ，去进行对 txt 文件的数据处理。不是 webshell ，我不觉得这个有什么安全问题。

@jifengg 做的是框架性通用性功能。如果要求服务器统一编码会限制通用性功能的使用范围。设计思路上是能减少一个用户要求，就减少一个用户环境要求。

而且，全流程 utf-8 会要求，不单单是服务器了。要求前端页面等也得 utf-8 、才能客户端浏览器以 utf-8 处理，这种传染形式，就更不利于框架性功能的推广了。

LZ 来讲讲各种不太大众的软件，漏掉推送消息的情况如何？

右边是基于 NMT 出的么？为啥我感觉还少了一些的？

用 pmap 和 gdb dump 再深入看看？

一般都是连接泄露
lsof -n -P > result.txt
然后拿下来看。

如果超大量 CLOSE_WAIT ，要考虑内部存在的服务请求等网络请求、在超时设定上的合理性。内层网络调用超时应小于外层网络调用超时，并逐层保证。如果使用 netty 等非线程池、使用事件 LOOP 处理的，更会容易触发此种情况。

同时，可以通过 jstack 等做个 threaddump 分析，有可能快速定位问题程序栈位置。

LZ 得讲清楚限制并发的限制在哪里？
A 、B 现在有各多少能力，限制资源在 B 还是在 A 内的其他部分。交易场景可异步化程度如何。

如果只是构造 token ，假设你 token 需要 GUID 类似的全局唯一控制，那么 A 本身的生成 token 动作基本不应该受什么并发限制。如果 A 构造了 token 之后，A 还向 redis 等设施缓存，那么问题就变成 A->redis 的并发能力有多少。如果 redis 并发能力不够，是否要 redis 自身集群化；或按其他交易标识等信息 hash 化之后，分交易集群分别独立处理链条的方式。

如果 B 有并发能力限制，那么还要问 A->B 的请求是必须同步等待返回的，还是可以异步的；又还要问，A 是否可以对用户异步，是否可队列化请求，异步返回等等。

LZ 需求题干给的信息偏少，建议思路会很发散的。

当然如果胆大，直接在电池上戳好洞，就这么用下去，感觉也不是不行