一二面技术算法 三四面架构设计 五面 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 里完成这个逻辑。

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

不算 2pc，不是分两个阶段就是 2pc 的
不算
没得比

轻量锁的竞争是 JVM 利用 CAS 操作，尝试将对象的 Mark Word 更新为指向 Lock Record 的指针, 如果这时候其他线程已经持有锁, 那么这里就会失败

mybatis 的注解式 sql 是最鸡肋的一个，其它注解是比较先进的，但它和 sql 放一起可读性特别差, 如果有复杂 sql 不建议这么做。
至于使用 set 替换 autowired 其实是在搞复古，但如果想这么搞建议使用 Javasist 或者 asm 做字节码生成，看到大量重复无明显含义的代码很让人厌烦。
数据库那里应该是单库，那么直接用自增序列应该是性能最好且使用起来最方便的一种，标识 id 如果没有含义存在的价值就不大
多数据源生产实践中是大坑，能上分布式就上分布式，然后单应用就只连接一个库，想要做其它库操作直接调用其它模块

不限于 java 大多数语言都在去 xml 化，虽然它的描述能力更强，但冗余信息比较多不符合人的阅读习惯。具体到 Java 项目中 xml 已经越来越少了，Spring boot 中默认已经没有 xml 了，新的框架们尽管支持，但也都提供相应的注解使用方式。
注解从某种程度上来说有侵入性，且对于第三方的库除非使用字节码技术修改不然没办法直接使用注解；
xml 呢也有它的好处，集中式管理, 对业务代码无侵入, 比如 dubbo 的 xml 现在你想修改服务版本直接在一个文件中修改就好, 如果采用注解那么就要全局替换注解影响范围要大一些，此外还有调试的时候你可以在 xml 中选择只加载你需要测试的服务以及其依赖的服务，把其他的临时注释掉。

但新项目仍然建议使用注解方式，因为所谓的耦合性在实际的项目中并没有什么实际的影响，绝大多数情况下是可以忽略的, 同时可以更好的收敛我们的代码，在不滥用的情况下更清爽也高效

是否使用覆盖索引和 age 上面有没有索引有直接关系, 没有索引的话自然不会走覆盖索引, 而且你这个 age 还很有可能区分度 cardinality 不够或者数据量很小，CBO 发现全表扫描的 cost 反而比较小，那就直接扫全表喽

最简单的就是锁喽, 比较适合单机情况。单机下还可以使用 LinkedBlockingQueue 、线程池(其实也是 LinkedBlockingQueue)等 juc 下的并发容器处理
分布式下可以考虑用消息队列, 前提是本身系统已经引入了一种消息队列, 不然额外引入一种消息队列的成本还有待商榷
想要轻量级就用个分布式锁，实现方式最好也与当前中间件结合，有 zk 用 zk，有 redis 用 redis, 啥都没有就用数据库或者文件去做

spring5 默认 jdk, spring boot2 默认 cglib