腾讯 or 蚂蚁

1. 方法不是 publicSpring 事务只对 public 方法生效，private/protected 不生效。2. 同类内部调用（this.方法）比如 A 方法无事务，调用同类里有 @Transactional 的 B 方法，事务不生效。原因：没走代理。3. 异常被 try-catch 吃掉了方法里 try-catch 了异常，没往外抛，Spring 感知不到，不会回滚。4. 抛出的异常不是默认类型默认只回滚 RuntimeException & Error。抛 Exception（受检异常）不回滚，需要加：@Transactional(rollbackFor = Exception.class)5. 没有被 Spring 管理类没加 @Service/@Component 等注解，没交给 Spring 容器，事务不生效。6. 多线程调用新线程里的操作不在原事务里，独立连接、独立事务。7. 数据库引擎不支持事务比如 MySQL MyISAM，本身不支持事务，怎么配都没用。8. 传播机制配置错误比如用了 NOT_SUPPORTED、NEVER，会以非事务方式执行。9. 类被代理方式问题（比如 CGLIB 对 final 方法）final / static 方法无法被代理，事务不生效。10. 开启了多个数据源但没指定事务管理器多数据源场景下，没指定对应 txManager，事务不生效。

1. 文章分类大概有多少文章？文章量一般从三个口径说：训练集、验证集、线上累计处理量。实际项目里常见是几万到几十万篇，线上累计处理量会更大。真正影响效果的不只是数量，还有类别是否均衡、长短文本分布是否正常。2. 怎么做的这个分类？怎么实现的呀？就是文本分类标准流程：先做文本清洗，再做标签体系，再做编码表示，最后接分类模型输出结果。如果用的是 BERT，就是文本经过 tokenizer 编码，输入 BERT，取 [CLS] 或池化向量，接线性层做分类。单标签分类一般用 softmax，多标签分类一般用 sigmoid。 from transformers import BertTokenizer...

一、 个人背景与综合意向- 自我介绍：请进行简单的自我介绍。- 业务背景：该规则引擎主要应用于唯品会的哪些具体业务场景？- 团队情况：你所在组的整体开发团队规模是多少？纯后端开发人员有多少？- 实习时间：如果入职，什么时候可以开始实习？打算实习多长时间？二、 Java 基础（重点考察 HashMap）- 数据结构：请介绍一下 HashMap 内部的数据结构。- 设计原理：为什么 HashMap 要引入红黑树？这样设计的根本目的和好处是什么？- 底层支撑：为什么底层要基于数组加链表的形式来实现哈希表？数组的作用是什么？- 哈希计算：JDK 1.8 中，哈希函数是如何计算哈希值并确定元素在桶中位置的？（扰动函数的作用）- 并发安全：HashMap 是如何保证线程安全的？具体到 JDK 1.8，它是如何利用 CAS 和 synchronized 实现的？- 不安全场景：在多线程环境下使用普通的 HashMap 会出现哪些具体的并发安全问题？（例如：值覆盖、扩容死循环等）三、 Spring 框架- 核心机制：请解释一下 Spring 的循环依赖问题以及它是如何通过三级缓存解决的？- 缓存细节：每一级缓存分别存的是什么？为什么非要引入“三级缓存”而不能只用二级缓存？（涉及 Bean 生命周期与 AOP 适配）四、 项目深度挖掘（规则引擎）- 项目核心：请详细介绍一下你负责的规则引擎项目，包括你的角色和核心产出。- 难点与挑战：在该项目中，让你印象最深刻的技术难点或业务难点是什么？- 稳定性治理：你是如何实现规则的多版本快照和回滚功能的？- 数据库设计：为了兼容旧表并实现多版本功能，你在表结构上做了哪些具体修改？- 业务逻辑：当规则出现问题时，业务人员如何通过后台系统排查过去的执行情况？- **回调机制**：业务回调功能是如何设计的？为什么要做异步优化？- 可靠性考量：如果系统在回调过程中重启，线程池阻塞队列里的任务丢失了怎么办？如何保证数据一致性？- 性能优化：你是如何发现规则执行链路存在耗时问题的？具体的优化手段（核心与非核心链路拆分）是什么？- 系统指标：该系统的平均耗时（RT）和峰值 QPS 大约是多少？五、 工程能力与运维排查- 监控手段：你们是如何对线上规则的执行时间进行监控的？- 线上排查：如果线上出现问题，你的排查流程是什么？- 容器化知识：线上系统是容器化部署吗？你对 Docker 或 K8S 有多少了解？- 日志定位：在容器环境下，你如何查找和定位历史日志文件？

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花MySQL 作为持久化关系型数据库，具备强一致性特性；Redis 作为内存型缓存，具备高性能优势。二者作为异构存储，强一致性难以实现（需承担极高的性能损耗），因此绝大多数业务场景均以「最终一致性」为核心目标。以下将对主流一致性保证方案的执行流程、优缺点及适用场景进行详细解析，排序遵循「应用广泛程度+一致性强度」原则。核心背景：一致性问题的根源读写顺序异常：例如先更新缓存再更新数据库，在并发场景下易产生缓存脏数据；网络及系统故障：例如数据库更新成功，但缓存删除操作失败（如网络中...