要真防的话是防止不了的，就如 2 楼所言，防君子不防小人，收集证据是一种方法，但是如果他们的服务器不联网或者屏蔽了你们的中央服务器，这一招就没有办法了。

以往的做法就是，软件根据所部署系统的一些特征生成一个唯一标识（ UID ），软件厂商根据一些算法，例如使用私匙对这个唯一标识进行签名生成一个授权码。客户获取授权码之后进行配置，然后软件启动的时候获取 UID，并根据授权码和公匙进行校验。

需要指出的是以上方法如果系统环境被复制（在系统层面没有什么是不能模拟的），或者软件内置的公匙被替换为他们自己的，都会导致此方法失效。

估计未来一段时间仍然会有这种独立部署的需求存在，除非客户端是断网的，内部使用的（例如学校内的一些系统），否则现在绝大多数服务基本上都转变为 SaaS 模式了，多租户使用一组服务器，数据上进行隔离分区，不仅方便版本升级，也省去了客户部署的操作。

可以拿多少工资看一下各类招聘信息就知道了，这一点取决于各种维度的信息，上下浮动空间也是比较大的，据我所知 Java 后端初学者目前在上海的话 8K 应该是可以拿到的，常用的框架要熟练，个人建议不要进那种 10 人以下开发团队的公司，在你这个阶段学东西上手才是主要的，能够学到什么经验很大程度上取决于公司目前所用的技术栈。

技术方面，Java 后端 Web 开发的话在国内几乎可以肯定会用到 Spring （ IOC 、AOP ），最常用的组合还是 SSM （ Spring 、Spring MVC 、MyBatis ），说白了就是最基础的 CRUD 。

另外就是关于数据库的知识，小公司一般后端开发还包括事务、表结构设计、查询优化等等，没有规模之前可能无需考虑拓展性，能够实现需求就行。

还有就是后端开发还涉及到安全（认证和授权）、统计（报表以及其他批量任务），总之如果需要你自己去设计和实现这些需求的话，那么需要了解的知识还有很多。

上了点规模的就要考虑到并发情况下如何拓展扩容、如何保证数据的一致性，能够分析系统的瓶颈在哪个方面，可以使用什么样的技术和架构来应对。不过到了这个阶段，公司应该早就已经规划好该怎么做了，等你工作了几年有了经验你自然会知道下一步该怎么走，需要学习什么样的知识。

题外话，我自己之前本身是做游戏客户端的，属于前端开发了，本身对编程语言是有一定的了解的，转后端（ 2017 年）对于我而言最大的障碍和枯燥点在于，后端涉及到的知识范围太广了，各种术语名词，导致我在一开始学的时候看一篇文章，里面每一个字我都认识，但是就是不知道作者在说什么，但是单独去查每一个概念和知识又会涉及到另外的一些概念，没有应用场景很难去理解一个概念到底是什么，有什么用。

但是，别以为我说了这么多就是为了吓唬你，我走到现在除了自己本身对这些东西感兴趣以外，最重要的一点就是：不要放弃！当你对各种概念了然于心的时候，你真的会感谢自己在之前无数个夜晚为此所付出的努力。

这一次回复字数应该比较多了，我也不继续废话了，如果楼主真的喜欢想要踏入这一个行业，那就干吧，多用 Google 、多读好书！

我也遇到过，没有越狱，起初还以为是存储满了，但实际上还有 100 多个 G，一般重启完就好了，大概每一个月会出现一次，也没搞懂到底是哪里出了问题。

一种方法论，DDD 的作者根据自己的经验提炼得出的一套通用建模方法，分为战术模式（ tactical patterns ）和战略模式（ strategic patterns ），其中战略模式是比较难以理解和抽象的，同时也是最重要。战术模式则可以归结为类似设计模式一样的方法工具。

难以理解就意味着用的人少，不好推广，可能一些团队的 leader 会强推或者应用其中的一部分，我想说的是放弃它是非常容易的，不对其进行维护就行了，但是重新拾取起来就会非常困难了。就像 TDD 一样，在思维没有转变过来之前，很多人就会认为它是浪费时间浪费成本的开发模式。

破窗效应所引发的一个结果就是，如果团队中有一个人可以打破规则，并且不受约束和惩罚，那么其他人也会尝试挑战规则，最终的结果就是混乱。

还区块链呢，这个链啥时候重写不还是他们控制的吗，没有可观测性的区块链有什么意义呢？

升级的时候不要插入任何外置 USB 设备，包括拓展坞，否则有可能出现问题。

按照你想到的这两种方法，我觉得第一种是可行的，定时扫描任务表，处理任务，然后删除或标记为已处理。
这样当你处理任务的时候，参与事务，如果任务处理失败，下一次定时扫描还可以重试（因为任务的删除操作或标记操作随着失败被一同回滚了，因此下一次执行仍然可以达成执行条件）。

取决于你目前现有的技术框架，如果增加一个这样的定时任务表很简单的话那就按照简单的来做。

这种是日志型数据，即追加写的方式记录全量数据，所以要用到日志型数据库 /消息队列，后续消费可以进行批量处理或者流处理，产生派生数据（即基于记录的全量日志数据衍生出来作为分析目的数据模型）。

就像楼上各位说的，可选的工具很多，如果是需要实时分析的，我个人可能会使用 kafka，然后用各种消费者去生成派生数据，可以根据规模对消息进行分区，这样做是为了将写入和计算并行处理，提高整体处理的吞吐量。

建议看一下数据库内的数据实际上到底有没有更新数据。
然后在检查方法缓存的问题。
另外如果两个操作不是在一个线程内同步进行的（顺序执行），在异步的情况下有可能会导致第二个比第一个先执行，虽然几率很小，但很多情况下都是由于微小的失误造成的。

读已提交并不会覆盖未提交的数据，而是覆盖了另一个已提交的数据。

一般来讲，在读已提交的隔离级别下，如果两个事务试图尝试对同一条记录进行更改，那么就会推迟第二个事务的写，直至第一个事务提交或终止，具体采用的就是行级锁。

比如，两个并发的请求，尝试对一个计数器增加 1 的操作，很显然其中一个需要等待另一个事务提交或终止。
A 读取了计数器，假设为 100，+1，写回。
B 读取了计数器，假设为 100，+1，写回。
两个事务在开始的时候都读取的 100，但是经过自己+1 之后，都是 101，在写回的时候就会出现问题（业务上正确的应该是 102 才对）。
实际上这种操作属于覆盖，在读和写之间并不是原子的，也就是一个事务覆盖了另一个事务的写，破坏了数据的完整性，这就是丢失更新问题。就像是在 Java 多线程并发编程中，如果你不把一个静态变量声明为 volatile，且在加锁的代码块里面再次判断这个变量是否等于之前已知的状态，就有可能会发生覆盖（原子比较+设置），例如 Java 的单例双重检查。

解决这个问题可以对行数据增加乐观锁版本号（也就是原子比较+设置），在事务中对写入结果进行判断，例如：
UPDATE counter SET count = 101, version = 1 WHERE version = 0
如果结果返回影响数据为 0 条（代码判断），则终止当前事务，防止发生覆盖。也可以用 SELECT FOR UPDATE，加独占锁，这样另一个事物在读取同一条数据的时候会被阻塞。

在不修改表的前提下，可以将 B 表的相关特征（例如需要排除的一些条件列）同步到 A 表的库中（也就是说在 ra 建立一张新的表，用于存储 rb 的 B 表的部分数据，这一部分数据就是 B 表的子集）。同步的时机取决于对延迟的要求，可以定时同步，或者在更新 B 表的时候立即同步。

同步过来的这些数据跟 A 表应该具有某种对应关系吧，例如包含 XX 值、或者有外键关联的信息，这样就可以直接用 SQL 去过滤 A 表的数据了。

早就卸载知乎了，另外账号资料信息全部改掉了，然后改了一个随机密码丢掉了。

https://www.tongyongpe.net/
制作简单，工具全

自己实现一个类加载器，加载不同 SDK 的 jar 可行性如何？
就是说把厂商 SDK 的 jar 当做文件资源，不直接通过 gradle 打包，而是使用动态加载的方式载入需要的依赖。

@gbj OK，有值的情况下又不一样了，这个涉及到属性命名策略（ PropertyNamingStrategy ）以及你使用的是什么 JSON 库，如果你使用的是 SpringBoot 默认没有配置的话，那么默认用的是 Jackson，命名策略好像是骆峰式。

你让前端把字段名大小写改一下，或者使用 @JsonProperty 注解你的 VO 字段。

包装类型默认为 null，你这里 Integer 、BigDecimal 因为没有默认值，所以这个结果是符合预期的。

@GGGG430
1 、NULL 值并没有比空字符串占用更多的空间，反倒是如果一个列本身用 NULL 是很自然的选择，但是强行给了一个默认值，那么这个默认值反而比 NULL 值所占用的空间更大。
2 、关于索引，如果索引的值本身就很稀疏，那么使用默认值来替代 NULL 并不会有什么帮助（ b-tree ）。
3 、还是那句话，取决于使用场景和数据库 /存储引擎，如果明确告诉你使用 NULL 就会有问题，那么这个时候才应该考虑是不是要做此类优化，提前优化是万恶之源，而且此类优化效果也是微乎其微的，只是它的不利影响被放大了。

数据库 /存储引擎有很多选择，版本也有很多，很多网上的奇淫技巧只针对于特定的版本有效，没有必要纠结在这些小问题上，国内很多公众号、技术文章现在基本上都是广告居多，颇有点中医理论的味道。