1. 上次一面聊了你的项目，能再深入说说项目中遇到的最大挑战吗？最大的挑战是处理秒杀场景的高并发问题。当时模拟了一个促销活动，瞬间有几千个请求抢购商品。最初的实现是直接查数据库库存，然后扣减，结果出现了超卖问题，而且数据库压力特别大，响应很慢。我分析后发现主要有三个问题：数据库成为瓶颈，库存扣减不是原子操作，没有做流量控制。解决方案是多层优化。首先把库存预热到Redis，用Lua脚本保证扣减的原子性。Lua脚本先判断库存是否充足，充足才扣减，整个过程是原子的。然后在网关层用Sentinel做限流，超过阈值直接拒绝。订单创建改成异步的，扣完库存就返回，通过RabbitMQ慢慢处理订单。还做了一些...

双非不知名一本大三，打算先蹭一段实习，如果能学到东西可以留到秋招，公司不行到五月run暑假实习，但几家平台总共聊了400个投了20个简历，都是查看简历无后续。第一个是手搓的小ai项目，第二个是黑马的点评

假设 ThreadLocalMap 中的 Key（即 ThreadLocal 对象）是强引用，在一个方法内部创建了一个 ThreadLocal，用完之后，方法结束了，你希望这个 ThreadLocal 对象被回收。问题是 虽然代码中不再引用创建ThreadLocal时的 变量（强引用断开），但当前线程（通常是线程池中的核心线程，生命周期极长）的 ThreadLocalMap 依然持有 ThreadLocal 的另一个强引用。只要线程不挂，ThreadLocal 对象就永远无法被 GC 回收。这就是 Key 的内存泄漏。所以为了保证当外界不再使用 ThreadLocal 对象时，它能被 GC 正...