不会的八股记录

1.execute 方法和submit 方法提交任务到线程池的区别?

任务类型支持 execute 方法只能提交实现了 Runnable 接口的任务，且不支持返回值，无法获取任务的执行结果。 submit 方法既可以提交 Runnable 类型的任务，也可以提交 Callable 类型的任务。Callable 任务可以返回执行结果。

异常处理 execute 方法在任务执行过程中如果发生异常，会直接抛出并打印到控制台。 submit 方法不会直接抛出异常，异常会被封装在 Future 对象中，只有在调用 Future.get() 方法时才会抛出异常。

还知道哪些 ThreadLocal 的变种实现？

具体例子：

假设线程1先执行任务1，任务1是由线程A提交的，那么任务1会捕获线程A的TTL上下文。当线程1执行任务1时：

• 首先备份线程1自己的TTL上下文（可能是空的，也可能是之前任务留下的）
• 然后将任务1捕获的快照（即线程A的TTL上下文）设置到线程1中
• 执行任务1
• 执行完后，恢复线程1原来的TTL上下文

然后，线程1接着执行任务2，任务2是由线程B提交的，那么任务2会捕获线程B的TTL上下文。当线程1执行任务2时：

处理2000亿条数据的查询优化：水平/垂直分片（水平分片约等于分库 降低单机压力 ）读写分离与多级缓存 索引 查询sql优化 选择合适的存储引擎 架构：批处理+实时处理（kafka+flink)

（copy的感觉语言组织很好）

1、常见的方案有数据库自增ID、UUID、Redis生成和雪花算法。实际分布式场景下，雪花算法更常用，它将ID分为时间戳、机器ID和序列号三部分，性能高且趋势递增。但要注意时钟回拨问题，可通过记录上次生成时间戳或使用扩展版算法解决。 2、雪花算法的ID在时间戳维度是递增的，但同一毫秒多机器生成的ID可能乱序。如需严格单调递增，可用数据库号段模式：服务启动时申请一个ID范围，内存分配用完后再次申请，这样单服务内ID严格递增。 3、redo log是InnoDB的物理日志，崩溃恢复时重放提交的事务；undo log记录数据修改前的状态，用于回滚和MVCC读；binlog是MySQL Server层的逻辑日志，用于主从同步和数据备份。 4、主库将变更写入binlog，从库通过IO线程拉取binlog到relay log，再由SQL线程重放SQL实现同步。 5、优化索引时要减少回表和利用覆盖索引。索引失效常见于：违反最左前缀、对索引列计算、类型转换、LIKE左模糊匹配、OR连接非索引列等情况。 6、InnoDB索引用B+树实现，联合索引按字段从左到右排序。如果跳过左侧字段，因为b的值在全局无序，无法利用索引快速定位，导致失效。 7、当元素少且小时，用压缩列表节省内存；当元素多或大时，自动转为 "跳跃表+字典" 组合。跳跃表负责按分值排序，支持高效范围查询；字典负责成员到分值的映射，实现O(1)快速查分数。这种设计平衡了内存与性能。 8、跳表插入节点时，从最高层向右向下逐层搜索并记录小于目标的分值位置（update[]）；随后随机生成新节点层高，创建节点并按层将其插入：每层链接到对应update[]节点之后，并指向其原后继；最后更新跳表的最大层高和节点总数，实现高效定位与平衡插入。 9、Redis有6种淘汰策略，常用的是allkeys-lru和allkeys-lfu。LRU淘汰最近最少访问的，LFU淘汰访问频率最低的。LFU更适合长期热点场景，而LRU对突发流量更敏感。 10、Redis用惰性删除+定期删除组合：访问key时检查过期，同时后台定期抽样清理过期key。当内存不足时，再根据淘汰策略主动删除数据。 11、TCP通过滑动窗口实现流量控制：接收方在ACK包中携带窗口大小。发送方根据这个窗口动态调整发送数据量，避免接收方缓冲区溢出。