webview 是个特殊的应用，它本质上是系统底层组件而不是应用程序，更新不了算是日常。另外 PlayStore 的最佳用法是静默更新——啥都不管让它自己去鼓捣，不需要手动去管理更新。

@thtznet #8 你要这样认为，那你很适合用记事本（ windows 自带那个记事本）编码。

HR 的话，别信。

你实际上是找工作经验少，找的多了就知道，假如 HR 这样跟你谈，那说明你对于这个岗位来说至少是可有可无的，大概率还是准备用完即弃的。

全 ORM 的惯例是：
保存（新增或修改）返回修改后的实体；
单独的新增方法返回新增后的实体或者主键；
单独的增量修改方法返回修改后的实体或者主键；
删除返回删除前的重新查询的实体；
批量 /动态修改，及批量 /动态删除，返回实际受影响的行数。

惯例只是惯例，是否遵循取决于自身得需要。但是，绝对不能为了代码美观而不要返回值。

我看了回复才发现你任务队列长度是 1 ，那一次性提交 10 个任务，出错是正常的，不出错才有问题。

这个 ThreadPoolExector ，Executor 执行器才是关键，ThreadPool 线程池只是执行器的一种实现方式（虽然 Java 就这一种实现方式，但其他语言会有其他方式）。

然后你的问题，你已经回答了，call()方法执行完毕，确实不算一个任务完成。service.take()执行完成后，可以确定 call()方法执行完了，通常也代表任务执行完了，但是执行器内部有没有把任务标记为完成，就不好说了，一般会有少量的延迟。

最后，我看了一下你的错误信息，里面有这么一句：

.ThreadPoolExecutor@2133c8f8[Running, pool size = 10, active threads = 2, queued tasks = 0, completed tasks = 10]

注意这个 active threads = 2 ，第一个 10 个任务完成之后，执行器有可能做优化了，就留 2 个线程，毕竟你队列长度是 1 ，2 个线程足够了。

你是想用缓存，还是要线程加锁，还是要利用定时自动解锁做业务逻辑。如果是线程加锁的话，用 await 、wait 、notify 这些线程通信机制来解锁会更有效，实在不行，你还可以用 sleep 。如果是另外两个场景，用 Redis ，比自己搞，更简单还更可靠。

@mytsing520 #10 STEAM 真不要开客户端 2FA ，那玩意的主要目的不是 2FA ，是防止账号共享，老老实实用邮件 2FA 最靠谱。

实际上，不要轻易尝试任何没有备用解锁手段的 2FA 。开 2FA 的时候，给你的备用解锁手段，或者二维码，或者二维码代表的 Code 信息，一定要保存好，丢失了你就只能哭。如果上面的东西都丢失了，服务商还能让你轻易解锁账号，那这服务商肯定不靠谱。不开 2FA ，或者用短信验证做 2FA ，本质上是用安全性换易用性，重要账号不能这么干。

目前最有效的 2FA 工具，是标准 TOTP 工具，例如 Keepass + Tray TOTP 插件，用这些工具再加上适当的备份措施，能让你安心的用任何标准 TOTP 方式的 2FA 验证。很有效并且还很方便的 2FA 工具，那就只有微软 Authenticator 、谷歌身份验证器，不考虑平台通用的话还可以加上苹果钥匙串。这三个大厂有很多备用方式能够定位到“你就是你”，当客户端丢失之后会让用户在找回来。小厂通常没办法定位“你就是你”，客户端丢了就丢了很难找回来（或者能随便找回来这样就没安全性了）。而像阿里这样的国内大厂，投广告防爬虫的时候，能有海量的数据定位到“你就是你”，儿童误消费退款、账号解锁的时候，或者任何处理仅对用户有利的情况的时候，哪些数据就集体失效了。

文档协作和云笔记，基本上都是事件存储+读写分离架构，不存在数据丢失的问题，但是会发生合并乱序。合并乱序要处理不好，就会发生最新修改被之前的修改掩盖的现象（看起来就像最近的修改丢失了）。但是因为事件已经存储了（表现在界面上就是历史记录），一般都是能人工救回来的。

注意合并乱序不一定是多终端才会发生，单终端也会发生，因为服务器和客户端也是两方合并。网络不稳定的时候就很容易发生合并乱序。

合并乱序问题很不好解决，微软 OneNote 已经鸡贼的不自动处理了，发生乱序就当成合并冲突，让你自己处理。看目前的情况，有道云笔记还在自动处理，并且自动处理成功率很低。

除非是自动化生产，产品序列号都是先定义一批然后再分发到生产上的，这样的化，Excel 集生成、管理、与其他系统继承（导入导出）一体，且操作简单，没有比 Excel 更合适的。

楼上那些说 UUID 的，多看一眼，产品序列号不只是主键，不能随便生成。

猜测：商务、资质等上面是买的，技术上是爬的。技术上超过买的部分不会超过一半，因为如果超过了，数据来源方完全可以踢开这些查查自己搞。

搞技术的人，最应该懂得，技术才是最容易的，难得是合规。

这种自动邮件，是模板生成的，标记垃圾邮件，一标记一个准。切记不要点不感兴趣、退订这些，你只要点了，你就被识别成活人了。

你这个返回的列是动态的，这就算到 SQL 那里也不是动态查询，你每次动态选择的列，对 SQL 执行屁影响都没有。WHERE 条件每次都是随机生成的，这才是 ORM 或者 SQL 查询上的动态查询。

请先把你的动态查询给分成两个过程。首先，WHERE 条件动态是一个过程，用 JPA 的 Specification 。然后，返回列的动态是一个过程，这个简单的很，你不论如何都查询出来一个 Entity （ JPA 的要求也必须是一个 Entity 对应一套表），然后在将这个 Entity ，根据接口返回的需要，返回不同的 DTO/VO ，或者仅返回指定字段的 Map （看你的场景，返回哪些列是用得时候才知道的，这样返回 MAP 更合适）。

你还是改一下标题吧，你需要的是包含 DevOps 的运维平台，不是 DevOps 。或者再实话一点，你需要的是个主管运维、人力资源、信息中心的副总经理。

JVM 的内存上限是由 VM 而不是又运行程序控制的，严格的说它也是由操作系统（只不过是个 VM ）而非应用控制的。另外，JVM 能精确控制的只有堆内存，整个 VM 的内存（即 java.exe 进程占用的内存），它也是不精确控制的。

你说得这个方法，正是 h264 、h265 的基本原理。也许可能不叫做熵编码算法。

还有你的第一句话，我还是第一次听说利用人类视觉特点的压缩。

这属于社工的范畴，社工当中，技术只占很小一部分。而在固定的人群中找偷网络的人，压根就不需要任何技术手段。不过，通常 guest wifi 不需要找出是谁，QoS 即可，这本来就是给临时来人的时候临时用的。假如是固定客户端限制访问，guest wifi 这种方可反而不做限制，那说明网关是脑残（这样的脑残还挺多的）。

“详细信息”标签才是真正的进程管理，“进程”标签那下面的是“应用程序（运行中）”管理，后者有后期处理所以容易处理错。

既然是正式环境，那肯定有“删除”操作，不管是硬删除还是软删除，把这个用例放到最后做，那测试完数据自己也就删除了。测试完，还能留下能被用户看到的测试数据的，就先别管测试数据怎么清理了，先去检查一下测试用例吧，要么漏测，要么用例顺序不良。

有些东西倒是一旦经过就会留下不可消除的痕迹，比如日志、统计信息，还有大多只给后台看的东西，这些东西没法通过正常操作删除。简单点的话，测试完手工清理。高级点的话，正式环境的测试过程也当成常规过程看，这些数据就永久保留，做好标记即可，但这需要良好的系统功能设计和测试用例设计。