@kanemochi 非内推，很容易成为刷 KPI 的产物，还是谨慎一点。

@woshiaha 是的，之前也有自称淘宝，钉钉之类的，打电话问我有没有想跳槽，一个我怕是骗子，其次我怕是刷 KPI，我觉得内推还是可靠一些。

@hello2060 说的太夸张了，我能在中国混好都不容易了，一步一步走😂

下班到家，在公司怕被发现，不敢太猖狂😂

能不能给个宝贵的建议或意见

普通商品超卖有什么问题？机票都专门超卖，要考虑都是卖不掉的问题 。如果是秒杀等特殊商品，这里面学问大着呢，各种权重，实际上都是事务保证一致性，update 天然分布式锁，怎么出现超卖呢？只会出现缓存不一致，比如微信红包看到还有钱，实际却抢不到之类

<u>打电话最快<u>

天才思想👍👍👍

mark, 好像 mybatis 也有动态构建 SQL 语句的类。SQL 表达力并不强，要不是微软也不用一直扩展 SQL 语法了。java 就是 java，SQL 就是 SQL 。没有银弹。

你这理解不对，首先说一下，公平只是相对的公平，所有公平模式，就是如果前面有线程排队就加入队尾，而非公平模式，就是线程直接尝试获取锁，获取失败才排队。但是线程本身的执行是没有顺序和优先级的。如果线程 2 因为 os 调度，一直得不到运行，可能一直永远排队。

简单的问题更简单，复杂的问题更复杂。用好 Stream 就能解决大部分问题了。自己学习写写 demo 还是能用的，现在 Reactive Programming 在后端不火，主要是调试理解困难，更重要的问题是后端应用最重要的 RDBMS，但是现在 RDBMS 只支持同步，如果支持异步，那样所以压力全都给了数据库，本来数据库压力就大。webflux 基于 netty，但是组件非常复杂，从前端可以学到，解决异步最成功实践还是 Promise，而不是 Rx

tieBreakOrder 作用的是干什么的？根本不是比较元素大小的，而是和它名字一样是打破比较的。这个只在插入的时候用到(红黑树不同元素一定要比较大小)。就是说在这一步一定要插入了，因为 tieBreakOrder 已经不关心 a,b 顺序了[也无法保证]。因为严格执行比较 identityHashCode 也可能相同，那样根本分不出大小。所以搜索都没有用 tieBreakOrder，而是在左右子树都进行搜索。实际上可以认为 tieBreakOrder 其实没有什么作用，前面比较都无法通过，则直接令 a<b 就可以。
可以看一下 Implementation notes. 有说明。

建议创建线程池时传 ThreadFactory 参数，打印不要用 System.out.println，请换成 log 可以查看是具体那条线程。inner 线程池最大任务数 = 12 + 1 （建议不要设置非核心线程）。出现这个问题并没有什么高深的原理，仅仅是线程运行的不确定性，第一轮 outter 给 inner 提交了 9 个 task，此时 inner 正常，outter 三个线程被正确的阻塞。当 inner 运行所有 countDown 后，第一轮 inner 执行还没完全结束，outter 三个线程被唤醒，**注意**，此时线程执行没有了先后顺序和逻辑关系，完全靠 os 调度器调度，如果第二轮 outter 线程三个线程先提交任务，此时 inner 线程池最多可以接受 4 个任务，就是说这一轮已经可能出现错误了。而且一旦触发 RejectedExecutionException，try-catch 没有捕获这个异常，则直接杀死 outter 的核心线程，造成 outter 线程池，execute->Rejected->kill thread->create thread->execute 的恶性循环。代码根本没走到 await，所以一旦 Rejected 就不再阻塞了。

我觉得对 redis 理解不够，这一条还是比较公正的。不顾使用场景就设计业务，不是有问题吗？ redis 为什么只被当做缓存？而且只能是缓存？库存，下单这种操作都没听说用 redis，你红包竟然用 redis 更新。redis 做分布式锁就更不谈了。是不是还 redis 做消息队列，注册中心。如果对你有冒犯，那提前说声对不起。

老哥是不是跳槽有点频繁

不要以为 JDBC addBatch 和 mybatis BatchExecutor 就是真正的批量提交!!!这个功能要先开启才能用，在 JDBC url 后面加 rewriteBatchedStatements=true，不然还是走的循环插入。

我觉得是你的问题，面试是双方考察，而且是技术 leader 这种级别的了，应该平等的聊天。在聊天中顺便稍微问一下技术相关的问题，而且主要用的是什么技术，人人都要去写内核吗？而且 TCP 这种问题真的毫无价值，怎么不背一下滕王阁序呢？

???这个问题不懂的话，建议先看 The Java Language Specification Java SE Edition.
重载是编译期就确定是哪个方法，如果还有个变元重载，那还更分不清了？？？
编译期确认方法三个阶段
1.不允许装箱拆箱 也不允许变元重载
2.允许装箱拆箱重载
3.允许装箱拆箱 允许变元重载，变元重载优先级最低

没什么一步方法，LAST_INSERT_ID()线程安全，但是是 connection 连接后上一个插入的自增 id，没插入前还没生成。
select auto_increment from information_schema.tables where table_schema ='db_name' and table_name='xxx';
线程不安全，auto_increment connection 共享。
所以保证原子性，一致性。只能用事务，先插入再更新。