独立进程出去，放专用调度框架上。

交易进程杂活线程太多不太好。

如有必要共享进度，进程间通信，用点数据库或者消息共享。

@MineDog 用户视角来看，同义不同设置，有点矛盾。做是可以做。但就是主题里说的不优雅了。

实际 => 当没有设置 file.encoding 时，取 file.encoding 会取得操作系统默认的 GBK ，不为空。导致不能强制走 UTF-8 。

我需求 => 当没有设置 file.encoding 时，强制走 UTF-8 。有设置时，走用户设置。

Strings.isNullOrEmpty(System.getProperty("file.encoding")) 是永假的

@v2wtf
@MineDog

@v2wtf tmpEncoding 会在没有设置-Dfile.encoding 时，拿到操作系统的默认 encoding => 为 GBK ，不为空

@v2wtf 当用户使用我研发的命令行工具进行文件处理时时，有指定 file.encoding ，则使用用户所指定的 encoding 。否则就强制使用 UTF-8 ，而不是操作系统默认值。

找了一下感觉得用 mbean……比较难看啊

个人理解如果出了 oom 之类的，对应影响到的线程如果没有做一些异常全捕获 Throwable 的话，线程自然是会退出

当然，除了 oom 整体进程能不能跑都是没准的了

三年了，200 多块钱全套的洋垃圾 hp T610 很是稳定。

洋垃圾 x86+三台 tplink mesh

@ungrown 大把双孔插头的用 Y 电容、包括氮化镓大功率的，一样也都是过 CCC 之类各种标准的。都是两孔插头，哪里来的良好接地呢…

还有其他各位提到的电压万用表什么的，或许首先还是搜下了解下什么是 Y 电容漏电流

现在的两口插头充电器上，Y 电容设计就会麻手，这个是 by design 的；而不是室电接地有问题、或者是简单隔绝可以解决的

Y 电容越大 EMI 就好做，但就麻手越明显；电容小 EMI 差。两者间的 trade off

@dem0ns 现在有哪些手机充电器可以换三孔的？果子自己 typec20w~30w 都没有的，除非英标

@dem0ns 三眼线是 MacBook 自带的吧，至少在 magsafe2 时代都是，一般不用买。但手机充电头还是要解决这个问题

真敏感交易，没有防重放么？

有防重放的话，比较一般的设计都就已经有摘要或加密了。最多搞个盐之类的简单弄弄，说得过去就行了

感觉是为了传播几个钓鱼的假检测工具、攻击队散播的消息？

https://mp.weixin.qq.com/s?__biz=MzIxMTg1ODAwNw==&mid=2247490415&idx=1&sn=9430dce59be87584273ed91108bb6a87&chksm=974fbc57a0383541acb03910d3dd3eb741717795a6d0d169d8b40b2f3728fc876da4e486e1bb&scene=126&sessionid=1659204593&key=e1ce1dd8aaf91119f27e47fc7d7c37d0ed26bec2efda22e839d27e8fa0099a868ae456c3ae7ecd05aaf5b0321a080f5364ab80b93fcc73ad65df07470e6ce7c1d060182e18aca3818565641f8f35eb7c215cc8052ddea5a4b2c40d75beb7acfc96c751808af8bfb2dc06c98976799ac0cf7c804c74e0f1770866c6412cc2b2db&ascene=15&uin=NTY2NTA4NjQ%3D&devicetype=Windows+Server+2016+x64&version=6307001e&lang=zh_CN&session_us=gh_0111d52251cf&exportkey=A0Y7oWOF0RCVKfxXgayDJgQ%3D&acctmode=0&pass_ticket=iYRgDlbnBcijnCJgWNhKRcNvUkVTmaTzzL6mOd7my8fRYa7%2B0jLezl7ZGnHIiSEW&wx_header=0&fontgear=2

SoftEther 用了十年用惯了
没高兴换 tailscale 或者 wireguard

@janxin 也就是必须要用了 TransformerFactory 的 XSLTC 特性 XSLT compilation feature ，类似要有

TransformerFactory.setAttribute("jar-name", "xxxx.jar")

之后才能触发？

然后就是，从防御角度，有什么办法全局显式关闭 XSLTC 特性么？

这种偶尔改个 bug 还行
要持续性的维护一个公开 api 的向下兼容性…还是算了吧
百度改一版你还得跟着改？没完没了了

@dcsuibian 要么抓明确的 IOException ，要抓上层就抓 Throwable ，抓 Exception 总感觉会漏

可以看一下这里，为什么要抓 Throwable
https://www.v2ex.com/t/638609

上海，180 开头
l2tp 回家、高端口 http 都没感觉到有影响

当你的 datanode 到了一定量的时候，这有上限的 namenode 不就得这么玩了么……