打包麻烦完全可以不打 fat jar （默认），使用 spring-boot-thin-maven-plugin 把三方包打出去，自己代码打包分分钟

配置文件的话直接 vim 修改, class 的使用 jar 命令先解压再压缩回去

@JasonLaw 默认是 dynamic 的，不要照本宣科

对于 innodb 来说 varchar 会和其他列存在一起, 而 text 存的是指针, 实际数据是在别的地方的，至于独立一张表影响索引效率的说法应该是历史问题，新版本里面是没有必要的，且不独立出去也不会影响索引的效率

前者计算是放在数据库进程，后者计算是放在应用进程，后者会浪费很多内存，前者会对数据库产生威胁，你要保大还是保小？

自己设计结构的话仿照 mysql 的索引使用 B+树去处理，多层 hash，这样速度会有提升，但索引本身是一份冗余数据，相当于空间换时间了

1.主流 mybatis, xml 虽然对人不友好但描述能力强对机器友好，喜欢单表操作可以直接用 mybatis-generate 插件生成实体和单表增删改查；
2.以后必然需要补 IOC 和 AOP 是必看，想系统一点可以以 bean 的生命周期展开，这是主线；
3. synchronized 和 juc 下工具类只能在单个 jvm 内生效，所以在分布式系统中不宜使用，锁的使用要看你项目的 tps 和 qps 只有高并发下使用多线程才会经常遇到这玩意，而大多数项目的使用者太少了；
4.jvm 分原理和诊断两个方面去学, 原理就是 jvm 模型，gc 算法，gc 模型，调参的话 zgc 都出来了普通开发者可以彻底告别调参了，诊断的话就是 jstat 、jmap 、jhat 这些，建议使用一些第三方监控工具让 jvm 更透明，比如 pinpoint 和 arthas，这些东西本身比较复杂可以先从会用开始

一二面技术算法 三四面架构设计 五面 leader 或 hr

@amiwrong123 只是举例，但像你说的不可能确实是不可能为 CANCELLED, 再分析下 PROPAGATE 是用在共享锁里面的，感觉这个!=0 可能是考虑了 CONDITION 这种情况，看的太久了已经忘了。。。你可以去看下 CONDITION 情况下有没有用到 release，如果没有用到那么这里就是等价于 SIGNAL 的

你这种情况前后之间交互就应该用分，这样只需要使用整数，然后让前端自己转就好了

CANCELLED，值为 1，表示当前的线程被取消；
SIGNAL，值为-1，表示当前节点的后继节点包含的线程需要运行，也就是 unpark ；
CONDITION，值为-2，表示当前节点在等待 condition，也就是在 condition 队列中；
PROPAGATE，值为-3，表示当前场景下后续的 acquireShared 能够得以执行；
值为 0，表示当前节点在 sync 队列中，等待着获取锁。

最简单的头结点锁包含的线程被取消了

lambda 里面的变量需要是 final 的, 使用的变量被隐式转为了 final， 编译器报错不是因为不会推断，而是你在给一个 final 变量重新赋值，手动加上 final 你就会知道真正的报错是在 neededList = new ArrayList<>(); 这里

@sonice 都有，Direct Memory 使用的是 Native memory/Off-heap，仍归属于 Java 进程，所以该部分内存本身是在用户空间的，但用户态和内核态之间的拷贝其实也被优化了，本质上是因为用户态的逻辑地址和内核态的逻辑地址
使用的是同一个物理空间，所以相当于用户态和内核态也不存在拷贝

Heap memory 堆内存：JVM 进程内的内存，由 JVM 管理以表示 Java 对象
Native memory/Off-heap：是在不在堆内的进程地址空间内分配的内存（还属于 JVM 的进程分配内存）
Direct Memory 直接内存：类似于本机，但也意味着正在共享硬件中的底层缓冲区。例如网络适配器或图形显示中的缓冲区。这里的目标是减少在内存中复制相同字节的次数
是分配在 C Heap 上的 Buffer，由于不属于 JVM HEAP，管理 /监控起来会比较困难，但也会被 GC 回收。DirectByteBuffer 自身是（ Java ）堆内的，它背后真正承载数据的 buffer 是在（ Java ）堆外——Native memory 中的

native heap: 本机内存(原指机器的所有内存，jvm 进程使用的也是它的一部分，但一般场景下经常指不属于 jvm 进程的内存)

Oracle 你想咋玩咋玩，它能兜底。mysql 就算了, 为什么互联网不喜欢把计算和业务放在数据库, 因为大量的长 IO 一不小心整个库就挂了, 等 mysql 再健壮点再考虑放些业务在里面

@tctc4869 只是个大概思路，细节需要你自己敲定，甚至也不一定要用注解，切面也可以

@tctc4869 这个不了解，感觉不一定有框架因为功能太小了，可以自己实现两个注解,一个用于实体, 一个用于字段, 然后实现 mybatis-plugin 的 Interceptor, 检测到 po 上有实体注解时就在数据删除后进行级联数据的删除(软删除和物理删除都行), 注解里面有表名, 然后在作为删除条件的字段上加上字段注解用来动态提取字段值

不要用外键, 不要用外键, 不要用外键。
而且 jpa 和 hibernate 上才有使用这东西的价值, 可以考虑在业务层做这种处理, 而像 mybatis 这种基本靠 sql 的可以直接在 sql 里完成这个逻辑。

都是浮云，直接给点简单业务场景让撸代码，给个几天甚至一周的时间，再提点需要实现的优化，嘴会骗人，代码不会(让别人写的话一见面对着代码聊立马就显原形了)