1.介绍下Java集合Fail-Fast、Fail-Safe机制（1）Fail-Fast（快速失败）​​​​定义​​：在集合迭代过程中，如果检测到结构被修改（如增删元素），立即抛出 ConcurrentModificationException，终止操作。​​实现原理​​：​​modCount 机制​​：集合内部维护一个 modCount（修改计数器），每次结构修改（如 add、remove）时递增。​​迭代器检查​​：迭代器初始化时记录当前 modCount 为 expectedModCount，每次调用 next() 或 remove() 时检查是否一致。final void checkF...

一面凉经 1.tcc介绍一下（见下）https://blog.csdn.net/m0_58719994/article/details/1316913922.事务的几种模式，- AT、TCC、Saga、XA模式分析- 四种分布式事务模式，分别在不同的时间被提出，每种模式都有它的适用场景AT 模式是无侵入的分布式事务解决方案，适用于不希望对业务进行改造的场景，几乎0学习成本。（1）阿里seata框架，实现了该模式。在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。二阶段提交：二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。（2）TCC 模式是高性能分布式事务解决方案，适用于核心系统等对性能有很高要求的场景。TCC 模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作；事务发起方在一阶段执行 Try 方式，在二阶段提交执行 Confirm 方法，二阶段回滚执行 Cancel 方法。TCC 三个方法描述：Try：资源的检测和预留；Confirm：执行的业务操作提交；要求 Try 成功 Confirm 一定要能成功；Cancel：预留资源释放；（3）Saga 模式是长事务解决方案，适用于业务流程长且需要保证事务最终一致性的业务系统，Saga 模式一阶段就会提交本地事务，无锁，长流程情况下可以保证性能，多用于渠道层、集成层业务系统。事务参与者可能是其它公司的服务或者是遗留系统的服务，无法进行改造和提供 TCC 要求的接口，也可以使用 Saga 模式。Saga模式的优势是：- 一阶段提交本地数据库事务，无锁，高性能；- 参与者可以采用事务驱动异步执行，高吞吐；- 补偿服务即正向服务的“反向”，易于理解，易于实现；（4）XA模式是分布式强一致性的解决方案，但性能低而使用较少。XA规范的基础是两阶段提交协议2PC。在XA模式下，需要有一个[全局]协调器，每一个数据库事务完成后，进行第一阶段预提交，并通知协调器，把结果给协调器。协调器等所有分支事务操作完成、都预提交后，进行第二步；第二步：协调器通知每个数据库进行逐个commit/rollback。其中，这个全局协调器就是XA模型中的TM角色，每个分支事务各自的数据库就是RM。原文链接：https://blog.csdn.net/ruiyiin/article/details/114633701https://zhuanlan.zhihu.com/p/785999543.redo log、binlog、undolog的日志有什么区别- redo log，一行记录就占了几十byte，只要包含了表空间号、数据页号、磁盘文件偏移量、修改值，再加上是顺序写，所以刷盘效率很高。- binlog日志是逻辑日志，记录内容是语句的原始逻辑，属于MySQL Server层。所有的存储引擎只要发生了数据更新，都会产生binlog日志。- MVCC的实现依赖：隐藏字段、Read View、undo log。在底层实现中，InnoDB通过数据行的DB_TRX_ID和Read View来判断数据的可见性，如不可见，则通过数据行DB_ROLL_PTR找到undo log中的历史版本。每个事务读到的数据版本可能是不一样的，在同一个事物里，用户只能看到该事务创建Read View之前已经提交的修改和该事务本身做的修改。原文：https://blog.csdn.net/qq_34222160/article/details/1244147754.手撕：重排链表

手撕：n个数范围是[1,n]怎么找出重复数字，并且不改变原来的数组，O(1)的空间复杂度类似环形链表，先定位重逢的点，然后从头开始定位重复元素，一开始没写出来面试官的提醒下最后还是oc了场景题：应该是挂在这了（1）怎么设计一个在线共同编辑的word结合场景等分析（2）如何处理sql慢查询大量请求响应缓慢核心目标​​：快速定位慢查询根源，针对性优化。​​步骤​​：​​监控与告警​​：使用工具（如 Prometheus + Grafana）监控数据库 QPS、慢查询比例、CPU/内存/磁盘 IO。设置慢查询阈值（如 MySQL 的 long_query_time=1s），触发告警。​​日志分析​​...

1.redission的底层实现（之前看过忘了），锁的续期逻辑，续期会使用啥https://blog.csdn.net/m0_71777195/article/details/1316741492.redission底层有使用过线程池吗3.redis的端口默认端口：6379：这是 Redis 的默认端口，用于客户端与 Redis 服务器之间的通信。集群模式：16379：在 Redis 集群模式下，通常使用这个端口来启动集群节点。4.算法题：最大不重复子串5. 优化器选择不走索引的情况1. 表数据量过小当表数据量 < 优化器阈值（通常几百行）时，全表扫描可能更快解决方案：无需优化，这是合理...

提问环节，想的美的说的美团！天气太热全程红脸，一面1.对大模型的了解（1）参数规模巨大大模型通常包含数十亿甚至万亿级参数（如GPT-3有1750亿参数），通过增加模型深度和宽度提升表征能力，能捕捉更复杂的模式和上下文关系。（2）预训练+微调范式采用两阶段训练：预训练：在无标注文本（如书籍、网页）上通过自监督学习（如掩码语言建模、自回归生成）获取通用知识。微调：针对特定任务（如问答、翻译）用少量标注数据调整模型，适配下游应用。（3）基于Transformer架构依赖自注意力机制（Self-Attention）并行处理长序列，突破传统RNN的梯度消失限制，显著提升对上下文的理解能力。通用性与泛化能力2.es如何进行数据聚合，不同表的数据聚合3.binlog的三种数据形式MySQL的binlog日志是数据库实现主从复制、数据恢复等功能的重要工具，它提供了三种不同的记录格式，分别为Statement、Row和Mixed格式。Statement（基于SQL语句的复制，SBR）Statement格式的binlog会记录每一项更改数据的SQL语句本身。这意味着每当主库上执行了一个数据修改操作，其对应的SQL语句就会被完整地记录在binlog中。优点：记录的内容相对简洁，不包含每一行具体的变化细节，因此可以减少binlog日志的大小，节省磁盘IO，提升性能。缺点：由于仅仅记录了SQL语句，为了在备库上精确重现主库的执行效果，还需要记录诸如session变量、用户定义变量等相关上下文信息，以防备库因环境差异而导致执行结果不同。对于涉及特定存储过程、函数、触发器调用的情况，可能无法确保复制的一致性。Row（基于行的复制，RBR）Row格式的binlog不再记录SQL语句，而是直接记录数据行级别的更改详情。优点：明确记录了每一行数据的修改细节，能精确反映数据变化，避免了SBR中可能出现的复制一致性问题。即使在主从服务器的表结构稍有差异或者存在触发器、函数等情况，也能确保复制的正确性。缺点：由于需要记录每一行的具体修改，可能导致binlog日志量增大，占用更多存储空间，增加网络传输负担。Mixed（混合模式复制，MBR）Mixed格式则是对前两种格式的综合运用，MySQL会智能地根据执行的具体SQL语句选择合适的日志记录方式。特点：对于大多数常规SQL语句，MySQL会选择使用Statement格式记录binlog，以减少日志量。当遇到那些在备库上直接执行原始SQL语句无法达到与主库相同效果的情况，如涉及不确定性的函数、存储过程、触发器等，MySQL会自动切换到Row格式，确保复制的准确性。通过灵活运用Mixed格式，MySQL既能尽量减小binlog日志大小，又能最大程度地保障主从复制的一致性。参考链接：https://blog.csdn.net/unbuntu_luo/article/details/1439449044. 消息的最终一致性消息队列（MQ）系统中，确保最终一致性通常涉及以下几个关键策略：1. 消息持久化持久化存储：将消息存储在持久化存储中，以防系统崩溃后数据丢失。确认机制：消费者在处理完消息后发送确认（ACK），确保消息不会被丢失。2. 消息重试重试机制：在处理消息失败时，允许系统重新处理消息，直到成功为止。死信队列：将无法处理的消息转移到死信队列，以便后续分析和处理。3. 幂等性设计幂等操作：确保同一消息被处理多次时，不会影响最终结果，避免数据重复。4. 顺序保证顺序消费：在需要顺序处理的场景中，确保消息按照特定顺序被消费。5. 最终一致性模型异步更新：允许系统在短时间内出现不一致状态，但最终会通过后台任务或补偿机制达到一致性。版本控制：使用版本号或时间戳来跟踪数据变化，确保数据在更新时的一致性。6. 监控与告警实时监控：监控消息队列的状态和处理情况，及时发现并处理异常。告警机制：设置告警规则，当系统出现异常时及时通知相关人员。

一半八股一半项目无手撕，总结不会的问题，已OC1.RocketMQ怎么确保消息仅消费一次（面试官的意思这几个常用的MQ仅仅RocketMQ通过拓展功能可以保证唯一消费一次）：一开始回答了消息的幂等性用唯一id保证，还可以把对应消费的状态存在redis里面还有mysql里面分多级缓存，如果对应id还是消费中的状态就可以进行重新消费，然后面试官的意思是RocketMQ通过拓展功能可以保证唯一消费一次（这个确实不太懂）RocketMQ 的 Exactly-Once 投递语义，就是用于解决幂等问题。Exactly-Once 是指发送到消息系统的消息只能被消费端处理且仅处理一次，即使生产端重试消息发送导致某消息重复投递，该消息在消费端也只被消费一次。最佳的幂等处理方式还是需要有一个唯一的业务标识，虽然每条消息都有 MessageId，但是不建议用 MessageId 来做幂等判断，在发送消息的时候，可以为每条消息设置一个 MessageKey，这个 MessageKey 就可以用来做业务的唯一标识。参考：https://www.nowcoder.com/discuss/353148811591753728?sourceSSR=search*************************************************使用文档可以参考https://github.com/Jaskey/RocketMQDedupListener ，2.CMS垃圾回收过程，重新标记阶段是怎么实现的，怎么确保效率（之前没了解过增量并发标记、satb）CMS采用的是增量并发标记，G1中使用的是SATB（Snapshot-At-The-Beginning）算法漏标问题：三色标记（1）已被遍历标记过的黑色对象重新引用了该白色对象；（2）删除了全部从灰色对象到该白色对象的直接或间接引用。处理漏标（1）CMS 是基于增量更新来做并发标记的。增量更新要破坏的是第一个条件，当黑色对象插入新的指向白色对象的引用关系时，就将这个新插入的引用记录下来，等并发扫描结束之后，再将这些记录过的引用关系中的黑色对象为根，重新扫描一次。这可以简化理解为，黑色对象一旦新插入了指向白色对象的引用之后，它就变回灰色对象了。（2）G1 是基于原始快照来做并发标记的。原始快照要破坏的是第二个条件，当灰色对象要删除指向白色对象的引用关系时，就将这个要删除的引用记录下来（使用一个快照记录标记过程中新分配的对象），在并发扫描结束之后，再将这些记录过的引用关系中的灰色对象为根，重新扫描一次。这也可以简化理解为，无论引用关系删除与否，都会按照刚刚开始扫描那一刻的对象图快照来进行搜索。其他：CMS和G1的区别（1）在 G1 收集器出现之前的所有其他收集器，包括 CMS 在内，垃圾收集的目标范围要么是整个新生代（Minor GC），要么就是整个老年代（Major GC），再要么就是整个 Java 堆（Full GC）。（2）G1 把堆内存分割为很多不相关的区域（Region，物理上不连续区分，逻辑上是连续区分 Eden 区、Survivor区，old区），Region 作为单次回收的最小单元，它可以面向堆内存任何部分来组成回收集（Collection Set，一般简称 CSet）进行回收，衡量标准不再是它属于哪个分代，而是哪块内存中存放的垃圾数量最多，回收收益最大，这就是 G1 收集器的 Mixed GC模式。参考：https://blog.csdn.net/longool/article/details/1407367403.JDK21引入的虚拟线程的概念：有点模糊，协程我以为不会问没背传统线程（1）绿色线程-定义：早期 Java 使用的一种线程模型，由 JVM 完成调度和管理，属于 M:1 线程映射模型。缺点：由于无法充分利用硬件性能，且实现复杂，最终被淘汰。（2）平台线程-定义：Java 1.2 之后采用的线程模型，依赖于操作系统的支持，属于 1:1 线程映射模型。优点：执行效率高，但开启和关闭线程的资源消耗较大。存在问题在内存有限的情况下，使用传统平台线程处理大量 IO 密集型请求,线程数量有限，会导致 CPU 利用率低。虚拟线程是轻量级线程（类似于 Go 中的 “协程（Goroutine）”），是由Java虚拟机调度，而不是操作系统。虚拟线程占用空间小，任务切换开销几乎可以忽略不计，因此可以极大量地创建和使用。JVM 使用 M:N 来完成虚拟线程与本地线程的映射。虚拟线程和线程池的异同看上去虚拟线程和线程池有类似之处，都是利用M个内核线程，完成N个任务，而避免平台线程频繁的创建和销毁。但他们是有本质区别的：（1）线程池中的正在执行的任务只有到任务执行完成后，才会释放平台线程，如果某个任务在执行过程中发生IO阻塞也不会被挂起执行其他任务。（2）虚拟线程中运行的代码调用阻塞I/O操作时，Java运行时会挂起虚拟线程，然后切换到另一个可执行的虚拟线程，直到它可以恢复为止。参考：https://blog.csdn.net/tianjindong0804/article/details/1350462714.分布式不同机器，写数据库了，怎么确保task消息的幂等性和同步更新（这里我回答了mysql的隔离级别，读已提交，还有主从）分布式事务：使用分布式事务管理器（如XA协议）来确保在多个数据库之间的一致性。5. 谈谈CompletableFuture（之前没了解过）https://www.nowcoder.com/discuss/686266738308055040?sourceSSR=search其他题目（1）CompletableFuture 和 Future 的区别，返回的是什么，怎么捕获异常（2）CompletableFuture 里的 all of 方法可以怎么实现（讲了 AtomicInteger 计数，他问还有没有，讲了信号量，他说其实还有 CountDownLatch）参考链接：https://www.nowcoder.com/feed/main/detail/b9d0579f8bfa46d8b44af7619a6f1b72?sourceSSR=search1. CompletableFutureCompletableFuture 是 Java 8 引入的类，用于支持异步编程。它实现了 Future 和 CompletionStage 接口，使得处理异步任务变得更加灵活和强大。2. Future 和 FutureTaskFuture: 是一个接口，表示一个异步计算的结果。它提供了方法来检查计算是否完成、获取结果或取消任务。FutureTask: 是 Future 的一个实现，允许将计算封装为一个可执行的任务。它可以在一个线程中运行，并可以通过 Future 接口的方法来获取结果。3. 异步任务使用 CompletableFuture 可以在后台线程中异步执行任务，而不会阻塞主线程。示例中使用 runAsync() 和 supplyAsync() 方法分别执行没有返回值和有返回值的任务。4. 任务依赖CompletableFuture 允许通过链式调用来构建复杂的任务依赖关系。常用的方法有：thenRun(): 在前一个任务完成后执行另一个任务，不接受参数且没有返回值。thenAccept(): 在前一个任务完成后消费结果，接受一个参数但没有返回值。thenApply(): 在前一个任务完成后处理结果，接受一个参数并返回一个新的 CompletableFuture。5. 并行任务anyOf(): 允许多个任务并行执行，并返回第一个完成的任务的结果。allOf(): 允许多个任务并行执行，等所有任务完成后聚合结果。6. 回调CompletableFuture 支持在某个任务完成后执行回调方法。常用的方法有：whenComplete(): 执行回调任务，没有返回值。handle(): 执行回调任务并返回结果，可以处理异常情况。6. 业务的动态部署总结：第一次面试，八股背的深度不够，好多细节遗漏接着面，接着背