魔兽争霸“官方”平台，自魔兽争霸升级 1.33 版本之后，平台就适配不上了，凡是战网平台开启自动更新的，现在战网平台和“官方”平台均没法玩。人要天天吃饭，游戏没人那么精贵，但基本上也要月月维护。真正的软件，不是你随便弄两个廉价劳动力就能搞定的。

还有，就算不是游戏从业者或者软件从业者，也应该知道运营、运维不是廉价的，至少不比码农廉价。

超时那个问题，把 future.get() ，换成:
try {
future.get(long timeout, TimeUnit unit);
} catch (TimeoutException e){
// 超时时候的处理，这里你想咋处理就咋处理，但是当前这个任务肯定是失败了。
}

提醒你一点：你提交给执 Executors 的是一个实现 Callable 接口的对象，不是 Callable 类的对象，这个对象不只有 call() 方法，是可以定义其他字段的。

所以你没必要在 call() 方法中去生成或申请那个资源，你可以在你实现 Callable 的类（别再用匿名类了）上定义一个字段来映射那个资源，然后在提交到 Executors 前就给它设值。这个设值过程，就跟线程池或异步执行器无关了，就是典型的单例模式。

上面不会解决你想要的超时处理。

@abc0123xyz 你要多个线程对同一个对象互斥，又要这个对象依赖的第三方对象能被多个线程复用。这是要一个并发场景下的共享对象，一部分状态是隔离的，另一部分状态是公用的，这是不可能的。

狗日的，我看你的描述头疼的很。

首先，你到底有没有这样的数据或者业务要求：最多一个线程处理它，如果是多个线程同时处理的时候，必须排队。如果没有的话，就别提在关注这一点。我看你的业务场景压根不涉及并发加锁。

台式显示器不出家门，甚至桌面都不出，做薄的好处就不大了，在考虑到做薄的坏处——刚性差、散热不好、设计成本等，自然就不会做薄了。当然高端装逼显示器，还是会做薄的，不过一般人没钱买而已。

拼音输入法重码太多，隐私跟输入效率只能二选一，不可能有完美的。如果愿意投入精力去学习的话，要像初中生那样投入精力，可以试试无重码方案的仓颉输入法，用 Rime 就可以支持。五笔据说没有记忆效应，停一段时间就全忘，而且五笔还是有重码的，所以不推荐。

没有私钥不行，因为根据私钥可以设置 pin 码这情况看，客户端每次登录都是要拿私钥重新生成签名的。

但是有一个方向楼主搞错了，SSH 无密码登录，不是服务器生成密钥对再分发的方向，而是客户端自行生成密钥对后把公钥报给服务器。这个方向是客户端主服务端从，不是服务器端主客户端从。当要在不吊销用户的情况下单独吊销登录凭证的时候，服务器唯一能做的就是 authorized_keys 中移除对应的公钥。所以这里建议要么一用户一人，要么一密钥对一人，不能共享的。

@optional 首先这是个好东西，楼主可以考虑直接用了。

然后还是要做下名词解释：
JPA 是 Java 实体持久化标准；
Hibernate 是 JPA 的一种实现库，类似的实现还有 EclipseLink 等等；
（背后的话，JPA 3.0 标准是基于 Hibernate 提取的，但这不影响 JPA 是独立标准；）
Spring Data JPA 是一个再次封装、更容易直接使用的库，它理论上是再封装 JPA ，但实际上是再封装 Hibernate ；
vladmihalcea/hibernate-types 这个，算是 Hibernate 核心的第三方扩展；

@muchenlou 我再看了以下，这个不只是类型映射的问题。PostgreSQL JSON 类型是非普遍的 SQL 类型，它连 JDBC type 都是自定义的 1111 ，这种情况 JPA 短时间（可能 10 年）内是不会考虑对它的支持的。这里就算你用 CUstom Basic Type 或者 Converter 解决了实体映射，在映射后的实体上也只能把它当成 Object/String 来用，最多当成只读的 JsonNode 。像部分修改 json 的值，通过 json 的特定属性来查询这些功能，都是用不了的。上面这些功能你必须要用脱离 JPA 标准的 NativeSql 来做。

我得建议是，不要再考虑映射 JSON 类型了。增加一个 varchar 或 clob 类型的列，映射到实体类的 String 类型上，额外限定该字段（对于实体类的上层应用来说）是只读的。原有的 JSON 类型的列，对实体类不可见，只能通过自定义 Repository 并使用 Native SQL 来访问，且自定义 Repository 需要负责这两个列的值的同步。当然如果你不需要 JSON 类型列的特定功能的话，你就直接 String 映射 varchar 或 clob 类型的列 即可，上层程序中自行处理 JSON 即可。

@HHHorz #11
@facelezz #15
看题，spring jpa ，这是 JPA 标准 Hibernate 实现，跟 mybatais 不是一个系列。

你对润这个字，有误解。

主键跟索引是两码事。

主键是键，在关系数据模型中是用来当做不同行之间的区分的。根据自然意义的需要，你应当从列当中选择最具代表性，且最少数量的列，当作主键。但这不是必须的，当选不出来的时候，你可以不要主键，这时候会有一个默认的候选键起作用，即所有列的组合。

索引是在主数据之外，用来辅助查询的额外数据。这其中，如果是树索引，且将主数据直接放到树的叶子节点上，这就是聚集索引。其他情况下是非聚集索引，这时候索引数据跟主数据是分开放的，索引上放的是主数据的地址或引用。

关系数据模型的键，不管是选择出来的主键，还是所有列组合的默认键，是一种天然的索引。这二者之间就这么点联系，其他时刻二者都是独立概念。聚集索引必然要用到这个天然索引，不然是无法将主数据跟索引放在一起的，非聚集索引就无所谓了。是否有主键，不影响是否能用聚集索引，但是是否有主键、主键是否单列、主键的值是否顺序，会极大的影响聚集索引的性能表现。

至于聚集索引有什么好处吗，我也不知道，大概是省了一份索引的空间占用吧。缺点倒是大得要命，它让性能参与主键选择策略。

你可以将 JSON 类型映射到 Jackson 的 JsonNode ，然后用 Jackson 的 API 或者 JsonPath 来读写这个 JsonNode

Spring JPA 的实现 Hibernate ，没有为 PostgreSQL JSON 类型提供基本类型映射，所以这个你只能自定义 BasicType 或者 Converter 。

通过 ID （单个或多个）查询数据，但却没给 ID ，这通常是错误调用，应当抛出异常，但这个异常就仅仅是参数无效异常，并不是提前暴漏出去的错误。

但是，非通常场景，比如说无需区分结果为空的原因是没给 ID 还是给了 ID 但没对应的数据，那穿个空的 ID 列表就是正常参数，无需抛出异常。

其实这个的关键还是要看你对 customerIdList 这个参数的定义，是允许空还是不允许空。

有两个问题：
第一，签名生成过程要私钥，授权开始时间还好说因为你这是人工授权，软件每次运行时间这种实时信息是没法进入签名的。软件每次运行时间这一块，你不联网是很难验证的。
第二，签名之后的证书信息或加密信息，你总要随软件主体一起给出，这个不用硬件加密狗就总有被复制的可能性。

错别字纠正：专门搞技术只是个技术 -> 专门搞技术只是个借口

@ZSeptember #15 你对这个技术误区的理解也是误区。专门搞技术只是个技术，真正的目的是避开酒局、无法自主控制的办公时间、不按套路出牌的甲方等各种烦心事。如果国内把业务沟通都限定在正常上班时间内的台面上，那时候就该找不到五年以上经验的编码人员了。