老板只懂一丁点技术还自大的才最要命…

@DreamSpace 数据库的可扩展性比上层应用差得多，因此资源也就要珍贵得多，上层应用开销大点问题不大，内存不够了，cpu 不够了，加机器就是了，相比较而言数据库就没那么简单了

有内存泄漏把，运行了 4 天，内存占用 400 多 M

建议图标换一下，和 time machine 总是会看错..

有点意思，来个微信小程序版就更通用了撒

和我去年入职情况一样，画了一个月理清逻辑后像头儿申请重构了，可以看看这个片段：
https://www.zhihu.com/question/20402322/answer/389075475

成都电信，去年 9 月初开通的 100M，两个月后免费涨到 230M 左右了，现在下载东西只要资源正常，可以达到 27~28MB，steam、暴雪 下载更新快的一批，并不存在所谓的速度上不去

Docker 是个好东西… 不用一直重装撒

虽然没人回我.. 但是还是自己回一个结论吧：该方案不可行，根本原因如下：

如果要实现数据库访问和业务开发独立，就意味着业务系统对数据的处理（如：映射 ResultSet 为对应的 Java 对象）和最终执行访问数据库的 JDBC 连接不是在一个服务内
JDBC 执行结果最终是返回 ResultSet，而 ResultSet 在该场景下存在两个问题
1. ResultSet 不可序列化，意味着远程服务调用没法直接返回
2. 数据库驱动对 ResultSet 的实现是持有数据库连接的，因为 ResultSet 从数据库中取值不一定是一次性加载，可能会在调用`ResultSet.next`根据需要多次通过 Connection 取值，这意味着远程返回给业务系统的 ResultSet 是不可能持有 Connection 的

针对问题 1：可以采用对不同的数据库驱动实现的 ResultSet 进行封装，这个还是属于可解决问题
针对问题 2：只能（在我看来只能）在业务系统上对的 ResultSet 的所有方法代理，转发给远程实际的 ResultSet 执行，但是这会导致两个系统之间的交互非常频繁，大大增加资源消耗和延迟。

也就是说，由于业务系统不持有数据库连接，如果要实现通用的数据库访问服务，那么就需要保证业务系统每一次调用都能直接获得完整的结果，这就需要对 ResultSet 的处理在数据库访问服务这一侧实现，而这部分逻辑是业务相关的，是在业务系统这一侧实现的。

@frozenthrone 封入口流量，不封出口

这么做完全没问题啊，既然枚举不同值需要实现不同的业务，那么本身就应该将其关联起来，代码实现非常清晰，也很好理解。分层什么的，本质上不就是为了业务逻辑更清晰、代码更易懂易维护？如果它成了束缚，那就应该及时打破。

@sh1nyan 我去查一下具体怎么玩，感谢！

@zhouyut001 有啊，现在唯一的烦恼就是端口不一致的问题了

@580a388da131 这就很奇怪了.. 昨天试了 N 次，都是只有相同的端口才能映射成功

@simonguo 我说的话是有前提的：生命安全事件 或 打出重伤。这种情况下，公司需要提供现场情况的视频。

@simonguo 办公区域防监控的最主要目的不是监控员工，而且留证据。公司要对员工负责，东西丢了还是什么的，都是小事，不打紧，要紧的就是如果出现生命安全事件才能有足够的证据。比如上次那个程序员和产品经理，如果最后打出重伤来，你说打官司的时候监控有多重要？

无脑喷.. 办公区域居然能不装监控？

@sujin190 是的，有 64 位的原子操作。之所以要强制对齐，原因是在 32 位平台下进行 64 位原子操作要求必须 8 字节对齐，否则程序会崩溃。这个在 1 楼贴出的文档里描述了，实际测试起来也确实是这样。