凯同学的面经(2025-8)

Eccentric 收录于 Java面试

2025-08-01 约 11141 字预计阅读 23 分钟次阅读

Boss直聘(2025-08-02)

1、写一道动态规划题目

从魔法师身上吸取的最大能量

在神秘的地牢中，n 个魔法师站成一排。每个魔法师都拥有一个属性，这个属性可以给你提供能量。有些魔法师可能会给你负能量，即从你身上吸取能量。

你被施加了一种诅咒，当你从魔法师 i 处吸收能量后，你将被立即传送到魔法师 (i + k) 处。这一过程将重复进行，直到你到达一个不存在 (i + k) 的魔法师为止。

换句话说，你将选择一个起点，然后以 k 为间隔跳跃，直到到达魔法师序列的末端，在过程中吸收所有的能量。

给定一个数组 energy 和一个整数k，返回你能获得的最大能量。

代码解析

说白了就是起点不知道但是终点范围固定，通过状态转移向前寻找最大值，起点就不用关心

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


public int maximumEnergy(int[] energy, int k) {
    int length = energy.length;
    int[] dp = new int[length + k];
    int res = Integer.MIN_VALUE;
    for(int i = length-1; i >= 0; i--){
        dp[i] = energy[i] + dp[i + k];
        res = Math.max(res, dp[i]);
    }
    return res;
}

通过范围进行二次循环，时间复杂度O(n),因为k是常量

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


class Solution {
    public int maximumEnergy(int[] energy, int k) {
        int length = energy.length;
        int[] dp = new int[length + k];
        int res = Integer.MIN_VALUE;
        for(int i = length-1; i >= 0; i--){
            dp[i] = energy[i] + dp[i + k];
            res = Math.max(res, dp[i]);
        }
        return res;
    }
}

2、线上sql优化经验、线上问题排查经验、主动优化问题经验

线上sql优化经验：

1、避免使用select *

2、小表驱动大表

3、优化分页查询

4、避免or连接条件

5、优先使用union all代替union

6、索引合理设计

线上问题排查经验：

总：稳定现场(止损优先)、科学排查、复盘改进

排查：指标->日志->调用链路->复盘改进

主动优化问题经验：

3、spring源码看过没有

4、mybatis plus源码看过没有，与你们的框架有什么不同

5、rabbitmq怎么保证消息不丢失的，有没有横向对比过其他mq

6、规则引擎听说过没，有哪些规则引擎

Drools: 规则与代码分离（DRL文件/决策表）、RETE算法优化、运行时动态加载规则【金融风控、保险理赔等需处理多层对象和自定义数据结构的复杂业务】
LiteFlow：支持任意编排规则、平滑热刷新、多级嵌套与外部存储扩展【兼容任意Java架构，学习成本低，分钟级上手】

7、用的哪种jvm，有没有对比过

8、java17有哪些新特性，有没有对比过每个版本

9、线程池线程是怎么复用的

线程池将线程和任务进⾏解耦，线程是线程，任务是任务，摆脱了之前通过 Thread 创建线程时的⼀个线程必须对应⼀个任务的限制。

在线程池中，同⼀个线程可以从阻塞队列中不断获取新任务来执⾏，其核⼼原理在于线程池对 Thread 进⾏了封装，并不是每次执⾏任务都会调⽤ Thread.start() 来创建新线程，⽽是让每个线程去执⾏⼀个“循环任务”，在这个“循环任务”中不停检查是否有任务需要被执⾏，如果有则直接执⾏，也就是调⽤任务中的 run ⽅法，将 run ⽅法当成⼀个普通的⽅法执⾏，通过这种⽅式只使⽤固定的线程就将所有任务的 run ⽅法串联起来。

线程复用依赖‌循环任务获取‌（while + getTask()）和‌阻塞队列调度‌，通过解耦线程与任务、动态管理线程生命周期实现高效复用

线程池的核心目标之一是避免频繁创建和销毁线程，通过线程复用提升性能。其复用机制主要依赖以下关键设计：

1、线程执行与任务解耦（工作线程调用任务的run()方法（同步执行），而非通过start()创建新线程）

2、阻塞队列实现任务调度（‌生产者-消费者模型、工作线程通过getTask()方法循环从队列取任务）

3、线程复用与控制策略（线程包装与状态管理、线程复用性保障）

10、多线程的使用场景

1、并发处理IO操作：IO操作时cpu处于空闲状态，多线程可以让CPU在等待IO时处理其他任务，减少整体耗时。

2、提升CPU利用率：计算密集型，可以将任务分配到多个CPU核心，避免单线程阻塞导致的资源浪费

3、异步任务处理：避免用户操作因等待任务而卡顿

4、并发服务设计：多线程可并行响应多个客户端，提升服务吞吐量

5、实时性要求较高的场景：分离不同优先级任务，确保高优先级任务不被阻塞

6、批量任务并行化：并行执行，减少耗时

线程池参数如何设置？

核心线程数：

CPU密集型任务：CPU核心数 + 1 避免过多线程竞争CPU导致上下文切换开销【+1：避免过度切换，应对短暂阻塞】
IO密集型任务：CPU核心数 * 2 充分利用线程等待IO的空闲时间

最大线程数：

需要大于核心线程数，一般是核心线程数 * 2
高并发场景需要压测，避免队列堆积或者资源耗尽

任务队列

有界队列 ArrayBlockQueue: 需设置合理容量，防止任务堆积导致内存溢出【队列满了之后生产者会被阻塞或者触发拒绝策略】
无界队列LinkBlockQueue: 使用与任务量波动平缓的场景，可能引发内存风险

空闲线程存活时间

非核心线程空闲超过此时间会被回收，通常设为 30秒~1分钟，平衡资源复用与释放效率

11、mysql为什么用innodb，有没有横向对比过？

‌**事务支持（ACID特性）**‌ InnoDB完全支持原子性、一致性、隔离性和持久性，适合金融、电商等需要严格数据一致性的场景。
‌行级锁定‌ 仅锁定操作行，极大提升高并发下的读写性能（如1000个用户同时修改不同订单）。
‌崩溃恢复能力‌ 通过事务日志（Redo Log）和Double Write Buffer机制，保障意外宕机后数据不丢失。
‌外键约束‌ 自动维护关联表的数据完整性，避免脏数据。
‌聚簇索引‌ 数据按主键物理排序存储，显著提升范围查询效率

InnoDB vs MyISAM（旧版默认引擎）‌

‌特性‌	‌InnoDB‌	‌MyISAM‌
‌事务支持‌	✔️ (ACID完备)	✖️
‌锁粒度‌	行级锁（高并发友好）	表级锁（写操作阻塞严重）
‌外键约束‌	✔️	✖️
‌崩溃恢复‌	自动恢复（安全）	易损毁（需手动修复）
‌全文索引‌	MySQL 5.6+支持	✔️（早期优势）
‌适用场景‌	写密集、高并发事务	只读或低频更新场景

‌典型场景差异‌：

MyISAM的COUNT(*)直接返回缓存值（快），但崩溃后表易损坏；
InnoDB需实时统计行数（慢），但数据安全性强

12、有哪些锁，重量级锁、轻量级锁等等

在Java并发编程中，锁机制用于管理线程同步，常见类型包括偏向锁、轻量级锁和重量级锁等，它们根据竞争场景优化性能。以下是主要锁的分类及其特点：

偏向锁‌：适用于单线程环境，无竞争时优化访问速度；当出现线程竞争时，会升级为轻量级锁。 轻量级锁‌：用于多线程交替执行同步代码块的场景，通过CAS操作减少性能开销；如果竞争加剧或升级失败，会进一步升级为重量级锁。 重量级锁‌：在激烈竞争环境下使用，涉及操作系统级互斥，性能消耗较大，但确保强一致性。 可重入锁‌：允许同一线程多次获取同一把锁（如Java的ReentrantLock），避免死锁。 非可重入锁‌：线程不能重复获取锁，简化设计但易导致死锁。 共享锁‌：允许多个线程同时读取资源，提高并发性。 独占锁‌：一次仅允许一个线程访问资源（如写操作），确保排他性。 公平锁‌：线程按请求顺序获取锁，避免饥饿。 非公平锁‌：不保证顺序，可能插队，提升吞吐量但增加不公平风险。 悲观锁‌：假设高冲突，操作前加锁（如synchronized），适合写密集型场景。 乐观锁‌：假设低冲突，使用版本号或CAS机制检测冲突，适合读密集型场景。 自旋锁‌：线程循环等待而非阻塞，减少上下文切换，但浪费CPU资源。 分布式锁‌：用于跨节点协调，确保分布式系统一致性（如Redis实现）。

锁的优化机制（如synchronized的锁升级路径）可进一步提升效率，但需根据具体应用场景选择合适类型。

13、项目管理的见解

以下是对程序员面试中回答“项目管理见解”的建议框架，结合技术视角与管理思维：

一、核心目标认知‌

项目管理的本质是在‌资源约束下交付业务价值‌：

技术层面：确保系统按时上线且符合质量要求（稳定、可维护、可扩展）商业层面：平衡需求范围、开发成本与交付时限（如通过MVP验证核心功能） 二、程序员的关键协作点‌ 需求转化‌：将模糊业务需求拆解为可执行技术任务（如用户故事→技术方案）主动识别需求矛盾点，推动需求方明确优先级风险前置‌：技术预研（如新技术选型）、架构设计阶段预留扩展性代码质量卡控（自动化测试、Code Review避免后期返工）透明沟通‌：用非技术语言同步进度阻塞（如“数据库瓶颈导致接口延迟2天”）定期输出技术简报（性能数据、技术债务评估） 三、敏捷实践建议‌ 迭代交付‌：拆分2周为一个迭代周期，快速验证核心模块度量驱动‌：跟踪代码交付速率（如Story Point/周）监控线上故障率（推动质量内建） 四、避坑经验‌ 变更控制‌：需求变更需书面确认，评估对技术架构的影响（避免无序迭代）技术负债管理‌：在规划中预留20%时间偿还债务（重构、文档补全）

回答示例‌

“作为程序员，我认为项目管理是技术与业务的翻译桥梁。例如在XX项目中，我通过将用户登录流程拆解为认证、鉴权、日志三个模块，并行开发缩短工期30%。同时每周用流程图向产品经理展示技术风险，共同决策砍掉非核心功能，最终提前两周上线MVP版本。”

⚡ ‌关键点‌：程序员回答此题需突出‌技术细节如何驱动管理决策‌（如架构设计影响排期、代码质量减少返工），而非泛谈理论。

14、有没有学习英语的习惯

15、工作中提升自己的习惯，文档编写

16、贪心算法与动态规划的区别

一、核心区别对比

‌维度‌	‌贪心算法‌	‌动态规划‌
‌决策视角‌	每一步选择当前局部最优解	从全局状态推导最优子结构
‌问题适用性‌	仅适用于具有贪心选择性质的问题（如部分背包问题）	适用于具有重叠子问题和最优子结构的问题（如0-1背包）
‌解的质量‌	可能得到局部最优解，不保证全局最优	严格保证全局最优解
‌计算复杂度‌	通常为线性或低阶多项式时间	需存储中间状态，时空复杂度较高
‌回溯机制‌	无回溯，决策不可逆	需回溯比较所有可能路径

二、典型场景分析

‌贪心算法适用场景‌
- ‌性质要求‌：问题需满足"贪心选择性质"（当前最优解能导向全局最优）
  
  案例：
  - 霍夫曼编码（每次合并频率最小的结点）
  - 部分背包问题（按价值密度优先装载）
- ‌局限‌：无法解决0-1背包问题（物品不可拆分时可能失效）
‌动态规划适用场景‌
- ‌性质要求‌：需同时满足‌最优子结构‌与‌重叠子问题‌
  
  经典问题‌：
  - 0-1背包问题（二维DP表存储子问题解）
  - 斐波那契数列（避免重复计算）
  - 最短路径（Floyd-Warshall算法）
- ‌优势‌：通过记忆化存储消除重复计算，保证最优性

三、直观理解差异（比喻）

以选择恋爱对象为例：

‌贪心算法‌：只看当前最佳条件（如"选最有钱的追求者"），不考虑长远发展
‌动态规划‌：综合评估未来潜力（如"分析谁可能成为潜力股"），追求长期最优结果

四、关键差异总结

‌特征‌	贪心算法	动态规划
‌决策依据‌	当前状态局部最优	历史状态全局推导
‌解空间探索‌	单一路径，无回溯	多路径比较，需回溯
‌最优解保证‌	依赖问题特性，不绝对	严格保证
‌效率‌	高效但可能次优	资源密集型但精确

⚠️ ‌选择原则‌：若问题验证满足贪心选择性（如最小生成树Prim算法），优先使用贪心提升效率；

当问题含重叠子结构且需精确解时（如编辑距离），必须采用动态规划

BOSS二面(2025-08-08)

1、redis是如何保证原子性的，setnx做了什么，为什么不用get + set

Redis原子性的保证机制

Redis通过以下核心机制确保操作的原子性：

‌单线程模型‌：Redis采用单线程处理命令请求，每个命令在执行过程中不会被其他线程中断。这意味着单个命令（如SET、GET或INC）是原子的，保证了数据一致性和完整性。
‌事务机制‌：通过MULTI开启事务，EXEC执行一组命令时，Redis确保这些命令要么全部成功执行，要么全部回滚（如失败时撤销所有操作）。这在处理批量操作时提供了原子性保证。
‌Lua脚本支持‌：执行Lua脚本时，脚本内的所有操作会被视为一个原子单元。Redis保证脚本执行期间不会被其他命令打断，适用于复杂逻辑（如先读取再更新）的原子性需求。

SETNX的作用详解

SETNX（Set if Not eXists）命令是Redis用于原子性检查和设置操作的经典工具：

‌基本机制：当执行SETNX key value时：
- 如果key不存在，则设置value并返回1（成功）。
- 如果key已存在，则不执行任何操作并返回0（失败）。这一过程是原子的，Redis的单线程模型确保多客户端并发时只有一个客户端能成功设置值。
‌应用场景‌：
- ‌分布式锁‌：客户端通过SETNX lock_key unique_value尝试获取锁。成功返回1的客户端获得独占访问权；失败返回0的客户端需等待重试。释放锁需结合Lua脚本验证值以避免误删。
- ‌幂等性控制‌：例如支付接口中，用订单ID作为key执行SETNX，防止重复处理同一请求（返回0表示已处理）。

为什么不用GET + SET

使用GET + SET组合无法保证原子性，而SETNX直接解决了这一问题：

‌竞态条件风险‌：GET和SET是两个独立命令。在多客户端并发场景下，多个客户端可能同时GET到key不存在的状态，然后都执行SET，导致多个客户端“同时”设置成功。这会破坏互斥性（如多个客户端同时获得锁），造成数据不一致或超额操作。
‌SETNX的原子性优势‌：SETNX将“检查并设置”合并为一个原子操作。Redis在执行时自动处理竞争，确保只有一个客户端能成功设置值，避免了GET + SET的非原子性问题23。这也解释了为什么分布式锁方案首选SETNX而非GET + SET组合。

综上，Redis的原子性依赖于单线程模型和专用命令（如SETNX），而GET + SET的分离特性使其不适合并发敏感场景。

2、事务回滚，缓存如何处理的，同一个事务呢？分布式事务呢？

3、jvm调优做过吗？垃圾回收器用的什么

4、java用的什么版本，17用过吗

5、项目优化讲一下

6、联合索引讲一下，什么场景会用联合索引，是只要组合字段就要加吗？联合索引的结构与单字段索引有什么不同？联合索引比单条索引快在哪

联合索引是数据库中由多个字段组成的索引结构，适用于多条件组合查询的场景。其核心原理、应用场景及与单列索引的差异如下：

一、联合索引的结构特性

‌排序规则分层‌ 联合索引按字段顺序构建B+树：
- 数据页‌先按第一列排序‌ → 第一列相同时按第二列排序 → 逐层递进
- 例如索引(department_id, hire_date)：
  1 2 3
  
  | department_id=1 | → hire_date='2024-01-01' → hire_date='2024-01-02' | department_id=2 | → hire_date='2024-01-01'

‌与单列索引的本质区别‌

‌类型‌	‌存储结构‌	‌查询覆盖性‌
单列索引	多个独立的B+树	仅覆盖当前字段条件
联合索引	单棵B+树按字段顺序分层排序	可覆盖多字段组合查询

二、适用场景与使用原则

‌必须使用联合索引的场景‌
- ‌多条件组合查询‌：WHERE a=? AND b=?（需符合最左前缀原则）
- ‌多字段排序/分组‌：ORDER BY a,b 或 GROUP BY a,b
- ‌覆盖索引优化：查询字段全部包含在索引中时，避免回表
  1 2
  
  -- 联合索引(a,b,c)时，此查询只需扫描索引 SELECT a, b FROM table WHERE a=1 AND b=2;
‌谨慎创建的场景‌
- ‌字段区分度低‌：如性别、状态等低基数字段，联合索引效果有限
- ‌高频单字段查询‌：若常单独查询字段b，应额外建单列索引（联合索引需a在前）
- ‌跳过首字段查询‌：WHERE b=? 无法使用索引(a,b)

三、性能优势的核心原因

‌减少磁盘IO与空间占用‌
- 一个联合索引替代多个单列索引，降低存储开销
- B+树层级更少，范围查询时减少磁盘寻道次数
‌**避免索引合并（Index Merge）**‌
- 单列索引处理多条件时需合并结果（交集/并集），额外消耗CPU和内存
- 联合索引直接定位复合条件的数据块，效率更高
‌覆盖索引加速查询‌
- ‌无需回表：当索引包含所有查询字段时，直接返回结果
  1 2
  
  -- 联合索引(a,b,c)可覆盖此查询 SELECT b, c FROM table WHERE a=1;

四、索引失效的典型陷阱

‌违反最左前缀原则‌

1
2
3


sqlCopy Code-- 索引(a,b,c)失效场景：
SELECT * FROM table WHERE b=2;          --  ❌ 缺少a
SELECT * FROM table WHERE a=1 AND c=3;   -- ✅ 用a；❌ c未用（b缺失中断链）

‌范围查询阻断后续字段‌

1
2


-- 索引(a,b,c)：
SELECT * FROM table WHERE a>1 AND b=2;  -- ✅ a用索引；❌ b,c失效（范围查询后字段无法排序）

‌函数操作或隐式转换‌

1

SELECT * FROM table WHERE DATE(a)='2024-01-01'; --  ❌ 索引列使用函数

五、设计建议

‌字段顺序优先级‌
- ‌高频查询字段放最左‌
- ‌高区分度字段优先‌（如用户ID > 性别）
- ‌等值查询字段‌ 置于 ‌范围查询字段‌ 前
‌避免冗余索引‌
- 索引(a,b)可覆盖(a)，无需额外建单列索引(a)
‌权衡写入性能‌
- 每增加一个索引，INSERT/UPDATE/DELETE效率下降约10%

‌总结‌：联合索引通过组合字段的B+树结构优化多条件查询，尤其适合高频组合筛选、排序及覆盖查询场景34。但需严格遵循最左前缀原则，并结合查询模式设计字段顺序，避免过度索引影响写入性能

7、集群有哪些，集群节点处理，并发量有多少

顺丰(2025-08-05)

1、介绍一下项目，具体业务流程，项目都是深度参与吗？

2、多语言问题处理、多币别处理、金额数据处理

3、线上sql慢，如何排查，执行计划有哪些需要注意的字段

‌一、慢SQL排查流程‌

‌开启慢查询日志‌
- 启用监控：SET GLOBAL slow_query_log = ON;
- 设置阈值（例：2秒）：SET GLOBAL long_query_time = 2;
- 记录未走索引查询：SET GLOBAL log_queries_not_using_indexes = ON;
- 日志输出位置：配置log_output=FILE/TABLE（文件或系统表mysql.slow_log）
注：生产环境建议阈值设为1-2秒，避免日志过大。
‌定位慢SQL‌
- 分析日志文件（默认路径：/var/lib/mysql/slow.log）
- 查询系统表：SELECT * FROM mysql.slow_log WHERE query_time > 2;
‌关联应用上下文‌
- 使用阿里Druid连接池：监控SQL执行时间、频次，关联接口和用户ID
- ELK日志分析：通过Filebeat采集慢日志至Elasticsearch，可视化分析慢SQL模式^

‌二、执行计划（EXPLAIN）核心字段解析‌

执行EXPLAIN SELECT ...后，重点关注以下字段：

‌字段‌	‌含义与优化重点‌	‌风险场景‌
‌type‌	访问类型（性能排序）：`const` > `ref` > `range` > `index` > `ALL`	`ALL`（全表扫描）需立即优化
‌key‌	实际使用的索引	为空表示未走索引
‌key_len‌	索引使用的字节数，联合索引中可判断是否充分利用	长度过短可能未用全索引
‌rows‌	预估扫描行数	数值远大于实际需优化
‌Extra‌	额外信息： • `Using filesort`：内存排序开销大 • `Using temporary`：临时表影响性能	出现这两项需优先优化

示例诊断逻辑： type=ALL + key=NULL → 未命中索引； rows=10000 + filtered=10% → 实际扫描1万行仅返回1千行，效率低下。

‌三、高频慢SQL优化方案‌

‌索引失效场景‌
- 违反最左前缀：索引(a,b)时，WHERE b=? 失效 → 调整查询条件或索引顺序3
- 隐式类型转换：WHERE varchar_col=123 导致类型转换 → 确保类型一致
- 函数操作：WHERE DATE(create_time)='2024-01-01' → 改为范围查询create_time BETWEEN...
‌锁竞争处理‌
- 表锁阻塞：大表DDL操作阻塞DML → 业务低峰期执行
- 行锁超时：长事务占用行锁 → 拆解事务或优化锁粒度
‌复杂查询拆解‌
- 多表关联（>3张表）：改为分步查询或使用物化视图
- 深度分页：LIMIT 100000,10 → 使用WHERE id > last_id LIMIT 10
‌数据访问优化‌
- 避免SELECT * → 仅查询必要字段
- 覆盖索引：索引包含所有查询字段（Extra显示Using index）

4、mysql与pgsql的执行计划一样吗？有什么区别

5、数据量大之后，分库分表如何实现，如何分（冷热、字段分片），分片后一个表数据量多大会比较合适。分库分表有哪些中间件

一、分库分表实现方法

‌冷热数据分离‌
- 核心思路：将高频访问的热数据（如最新视频）与低频访问的冷数据（如历史记录）物理分离。
  - ‌判断逻辑‌：基于访问频率或时间戳动态标记。例如，短视频应用中，播放次数达阈值自动迁移至高性能存储作为热数据，反之归档为冷数据。
  - ‌实现方式：
    - ‌透明分离‌：业务层无感知，仅性能差异（如热数据用SSD，冷数据用云存储）。
    - ‌自动化迁移‌：结合缓存层和中间件，实时监控访问模式调整数据状态。
  - ‌优势‌：提升系统性能和用户体验（减少锁争用），降低存储成本（冷数据用低成本云服务），增强数据安全性（独立备份策略）。
‌**字段分片（分区）**‌
- ‌水平分片：按行切分数据，常用分片键（如用户ID或时间）。
  - 例如，订单表按用户ID哈希分片，分散到多个库/表。
- ‌垂直分片：按列切分，分离高频和低频字段。
  - 例如，用户表拆分基本信息（热数据）和历史行为（冷数据）。
- ‌分片策略：
  - 基于目录的分片：使用查找服务映射键到分片，灵活性高但需管理复杂度。
  - 哈希或范围分片：确保数据均匀分布，避免热点。

二、分片后单表数据量合适阈值

阈值需综合数据量、性能及架构因素，并非绝对：

‌数据量参考‌： - 单表行数超过‌1000万行‌（或保守阈值500万行）时，B+树索引深度增加导致查询延迟显著上升。 - 表大小达‌50GB‌或数据库总大小超‌1TB‌，应考虑分库分表以优化I/O。
‌性能阈值‌： - 查询延迟超业务容忍值（如>2秒）、写入延迟增加或锁争用频繁时，需分片。 - 并发用户数激增导致数据库瓶颈（CPU/内存利用率>80%）。
‌阈值确认方法‌： - ‌拐点分析‌：监控查询响应时间突变点（如用户流失期限）。 - ‌二八法则‌：识别头部20%高频数据优先优化。
‌实际建议‌：预留20-30%冗余，定期评估数据增长趋势

6、线程有哪些启动方式，代码写了就是就是一个线程吗？线程池是如何使用的

7、一段很简单计算的代码，偶发执行很慢，可能有什么原因

8、mysql sql没走索引，可能有哪些原因？如何排查？大数据in为什么mysql会优化成全表扫描？

9、项目中树形结构长编码优化查询后，顶级节点长编码、长名称修改引起全表修改，怎么处理

10、分布式数据库（支持跨库事务）了解吗

11、nio了解吗？怎么实现的？os操作系统有没有对轮询（死循环）优化

12、netty框架了解吗？用过吗？

13、redis有哪些数据结构，一般怎么用的，性能为什么好，持久化策略，能保证数据不丢失吗？

14、大数据框架have等有了解吗？

15、平常自己有学习哪些技术相关的

16、redis如何保持高可用和同步数据，有哪些模式（主从等）

17、额外:线程与线程是如何通信的，线程之间是互相隔离的吗？进程之间又是互相隔离的吗？

目前顺丰使用技术为springboot、mybatisplus、mysql，ai优化使用的扣子、通义灵码之类的

顺丰二面(2025-08-12)

1、项目上碰到的问题，如何排查、优化

2、redis加锁问题，具体业务场景是什么

3、mysql等数据库死锁问题，如何排查处理

4、消息如何保障可靠，不丢失

5、场景题，有个拍卖场景，会有很多人多次举牌，大屏要显示实时数据，且拍卖会有时间限制，如何设计功能（拍卖的本地时间同步是不是服务器时间，拍卖得最高价实时显示）

6、api调用如何保证可靠性，版本切换的时候呢？（用version、字段判断）

7、tcp同时多个连接连上来的时候，如何保证可靠性（要防止压爆服务器，应该减少设备轮询次数）

8、喜欢什么样的团队氛围，9、一个需求的发生如何保证需求准确且不扩大范围

10、对于新同事、新团队之间，应该怎么赋能提升

11、自身发展路线是什么，如何学习呢？

12、需求与技术债务（指一些用临时方案处理的）处理、平衡

13、如何处理多线程并发问题

14、消息队列崩溃怎么办

技术还是spring 主要做采购、合同这一块需求

顺丰三面（2025-08-18）

1、苍穹能做到什么，不能做到什么，对比主流你认为有哪些优缺点，为什么这么设计

2、讲一个线上排查问题的案例

3、内存泄露是如何排查的

4、性能问题是如何排查的

5、redis集群架构、数据同步

6、有没有看过什么框架的源码

7、平常ai的使用有哪些，有用过哪些工具，ai的原理有看过吗

8、mysql redis看过哪些书，ai呢？（后续会问你看得什么名字，判断你有没有瞎说）

9、你觉得大学课程中对你影响最大的课程是什么

10、苍穹是怎么在业务代码里编织新的逻辑的（我讲了我们的op插件），优缺点是什么，原理呢？

平安（2025-08-06）

1、string“”与string对象 new string的区别，底层指向

2、object对象中线程通信的用法，notifyall（）是如何知道要通知哪些线程的

3、java中有哪些申明（注意，最新版本），比如class enum

4、请求并发、重发处理，后台如果判断是否是重复请求，比如app web都同时下单

5、对于这种并发，不加锁，不用消息队列，有没有更好的答案，性能更优的

6、如果后台业务并发修改同一行数据，是怎么处理，有没有不加锁的处理方法（乐观锁？）

7、分库分表，有哪些策略，会带来什么问题

8、设计模式，事件模式、代理模式、策略模式，后两个的区别

9、场景题

微博中，每个人都会被关注或者关注别人，其中有人发了一条新的微博，如何及时通知粉丝，如果是大v发呢？如果是大v的朋友圈（许多大v转发呢）数据库怎么设计，消息怎么及时通知

10、回文字符串判断

11、有一些课程，需要学习前置课程，给你一个二维数组

【1，2】【1，3】表示学习1需要前置学习2、3课程，可以同时学习多门课程，每门课程学习时间相同（例如同时学1、5、6，只需要一个单位）求最短时间需要多久学完

12、项目经历中比较复杂的，怎么优化的

13、如果包路径、类，与你的class路径，类一模一样，会发生什么

14、redis大key, redis 热点数据怎么处理？

平安二面（2025-08-11）

1、预算成本、xx成本、实际成本，是什么

2、应收应付，实收实付是什么

3、平安的业务了解多少？

4、平安的产品了解多少

5、财务知识了解多少

6、最近面了多久，有没有offer什么的（老登问题来了）

7、大数据量表join优化，达梦数据库与mysql的区别

科大讯飞(2025-08-08)

1、redis集群了解吗？有哪些当时，数据同步了解吗？

2、java.中自带的锁有哪些，可以锁方法可以锁对象吗？为什么要用分布式锁呢？java中的锁有用过吗？

3、springboot了解吗？spring呢，servlet处理呢，你们平台怎么处理的

4、bean的生命周期？苍穹平台怎么处理bean的，怎么生成对象的

5、数据库b树与b+树，哪个性能更好为什么？索引失效的情况

6、java8新特性（其实想问java17的估计）

7、stream流，与foreach区别，有性能提升吗？

8、线程池，什么是核心线程、最大线程、阻塞队列（等一些参数）

9、多线程数据处理，如果拿结果的？

10、capetablefuture，与funure区别，用过future吗？

11、模块设计，模块优化

12、培训、管理怎么做的

13、性能优化怎么排查的，怎么优化的

主要用spring cloud、mysql等技术，ai用自研产品，主要招人是为了成立一个部门维护大湾区的二开产品

目录