腾讯CDG（金融科技）测开面经

1. Linux查看CPU情况：使用 top 可实时查看系统CPU整体及各进程占用率，按 1 能展示每个核心运行状态； htop 以可视化界面增强交互性； mpstat -P ALL 精准统计每个CPU核心负载； lscpu 输出CPU架构、缓存等硬件信息； vmstat 综合展示CPU、内存、IO等资源使用趋势； sar -u 基于历史数据统计CPU负载； nproc 直接获取CPU核心数量。实际分析时，先用 top 快速定位异常，再结合 mpstat 等深入排查。 2. 电商退款测试用例：功能测试覆盖全额/部分退款、不同发货状态处理、退款金额计算及多渠道返还；异常测试包含重复退款、越权操作、网络中断恢复；业务规则聚焦退款时效控制、优惠券分摊逻辑、高频退款风控；同时补充兼容性（多终端适配）和性能测试（高并发场景响应），保障退款流程稳定可靠。 3. 死锁及其原因：死锁是多进程/线程因资源竞争形成互相等待、无法推进的阻塞状态，需同时满足互斥（资源独占）、请求保持（占有资源时请求其他资源）、不可剥夺（资源不能被强制释放）、循环等待（形成资源等待环路）四个条件。常见于数据库事务交叉锁定、多线程无序获取锁等场景，可通过资源预分配、顺序加锁预防，依赖日志或线程Dump分析检测。 4. 慢查询原因及定位：慢查询根源在于索引失效（未命中或设计不当）、数据量过大导致全表扫描、复杂查询（嵌套子查询、大量JOIN）、锁冲突（行锁升级表锁）、服务器资源瓶颈（CPU/IO过载）。定位时，先启用慢查询日志并用 pt-query-digest 分析高频慢SQL，再通过 EXPLAIN 剖析执行计划，结合 SHOW ENGINE INNODB STATUS 排查锁等待，必要时借助 Performance Schema 监控资源消耗。 5. 适合建索引的字段：优先对高频出现在 WHERE 、 JOIN 、 ORDER BY 子句中的字段建索引，尤其是高选择性字段（如身份证号、手机号）；组合索引遵循最左前缀原则；写入频繁字段谨慎建索引，避免影响性能；大字段类型可使用前缀索引优化查询。 6. InnoDB与MyISAM区别：InnoDB支持事务、外键和行级锁，采用聚簇索引存储数据，适合高并发读写场景，具备崩溃恢复能力；MyISAM使用表级锁，无事务支持，索引与数据分离存储， COUNT(*) 统计高效，但不适用于写密集业务。生产中InnoDB用于核心交易模块，MyISAM适用于只读统计类表。 7. InnoDB锁及表锁升级：InnoDB提供共享锁、排他锁、间隙锁等多种锁机制，并通过MVCC减少冲突。表锁升级常发生于SQL无法命中索引引发全表扫描、大事务更新大量数据导致自适应哈希索引失效、执行 ALTER TABLE 等DDL操作，以及死锁检测后强制升级场景。优化需确保索引覆盖查询，拆分大事务降低锁粒度。

OOM（Out of Memory） OOM即内存溢出，指程序运行时申请内存空间超过系统可分配的极限，导致系统无法满足请求，如Java中会抛出 OutOfMemoryError 异常。 常见原因： - 内存泄漏：对象不再使用却持续被引用，如静态集合引用大量对象未释放；单例模式持有外部资源引用，导致GC无法回收。 - 资源过度消耗：一次性加载超大文件、生成海量数据对象（如无限循环创建对象）；多线程并发导致栈内存不足。 常见类型： - 堆内存溢出：对象创建过多且无法回收，典型场景如频繁创建大对象，抛出 java.lang.OutOfMemoryError: Java heap space 。 - 元空间溢出（JDK 8后）：加载的类、常量池数据过多，超出元空间默认大小，报错 java.lang.OutOfMemoryError: Metaspace 。 - 线程栈溢出：线程创建过多或递归调用过深，导致栈空间耗尽，抛出 java.lang.StackOverflowError 。 AOP（Aspect-Oriented Programming） AOP是面向切面编程范式，通过将横切关注点（如日志记录、事务管理、权限校验、性能监控）与核心业务逻辑分离，提升代码复用性和可维护性。 核心概念： - 切面（Aspect）：封装横切逻辑的类，如 LogAspect 处理日志记录。 - 切入点（Pointcut）：定义拦截哪些方法，例如 execution(* com.example.service.*.*(..)) 匹配指定包下所有方法。 - 通知（Advice）：拦截到方法后执行的逻辑，分为 @Before （前通知）、 @After （后通知）、 @Around （环绕通知）等，如 @Around 可统计方法执行耗时。 - 织入（Weaving）：将切面逻辑插入目标方法的过程，可在编译期（AspectJ）、类加载期（AspectJ LTW）或运行期（Spring AOP动态代理）实现。 实现方式： - 动态代理：Spring AOP基于JDK动态代理或CGLIB，在运行时生成代理类，适用于轻量级应用。 - 字节码织入：AspectJ在编译期或类加载期修改字节码，支持更复杂的切面逻辑，但侵入性较高。 RPC（Remote Procedure Call） RPC是一种分布式通信技术，允许程序像调用本地方法一样调用远程服务，屏蔽网络传输、序列化等底层细节。 核心组件与流程： 1. 序列化/反序列化：将请求参数和返回值转为二进制（如Protobuf、JSON）或字节流传输，减少网络开销并保证数据兼容性。 2. 网络传输：基于TCP/UDP或HTTP协议（如gRPC基于HTTP/2）实现客户端与服务端通信。 3. 服务发现：通过注册中心（如Zookeeper、Nacos）定位目标服务地址，实现负载均衡和动态扩容。 4. 代理生成：客户端生成代理对象，封装网络请求逻辑，使开发者无需关注Socket连接、超时重试等细节。 常见框架： - gRPC：Google开发，基于HTTP/2协议，支持多语言，性能高效，适用于高并发场景。 - Dubbo：阿里巴巴开源，支持丰富的服务治理功能（如流量控制、服务降级），在Java生态广泛应用。 - Thrift：Apache项目，提供多种序列化协议和传输层实现，适用于跨语言分布式系统开发。

TCP建立连接需要通过三次握手，具体步骤如下： 1. 第一次握手 (SYN)：客户端发送SYN=1的报文，并随机生成一个序列号seq=x，随后进入SYN_SENT状态。 2. 第二次握手 (SYN+ACK)：服务器收到SYN报文后，发送SYN=1和ACK=1的应答报文，确认号为ack=x+1，同时自己也随机生成一个序列号seq=y，进入SYN_RCVD状态。 3. 第三次握手 (ACK)：客户端收到服务器的SYN+ACK报文后，发送ACK=1的确认报文，确认号为ack=y+1，序列号为seq=x+1，双方进入ESTABLISHED状态，连接建立完成。 两次握手不足以建立可靠的连接，主要原因如下： 1. 防止历史重复连接初始化造成的混乱：在网络延迟情况下，客户端可能发送多个SYN请求。如果只有两次握手，服务器无法区分这是新的连接请求还是旧的重复请求；而三次握手允许客户端确认是否接受这个连接。 2. 同步双方初始序列号：TCP需要可靠的序列号机制来保证数据有序传输。两次握手只能确保服务器知道客户端的初始序列号，三次握手确保双方都确认了对方的初始序列号。 3. 避免资源浪费：如果只有两次握手，服务器收到SYN就会建立连接并分配资源。当SYN是延迟的重复报文时，会导致服务器维护大量无效连接。 4. 防止已失效的连接请求到达服务器：在网络拥塞时，客户端可能重传SYN请求。如果只有两次握手，服务器会认为每个SYN都是新的连接请求；三次握手机制确保只有客户端确认后才真正建立连接。 假设只有两次握手：客户端发送SYN1(seq=100)，由于网络延迟未到达；客户端超时重传SYN2(seq=200)，成功建立连接并通信后关闭；此时延迟的SYN1(seq=100)到达服务器，服务器响应并认为连接已建立；但客户端不会处理这个连接，导致服务器资源被占用。而三次握手解决了这个问题，因为客户端会忽略服务器对SYN1的响应，不会发送第三次ACK。

1. JVM内存模型：JVM内存模型将运行时数据区域分为堆（Heap），用于存放对象实例，是垃圾回收的主要区域；方法区（Method Area），存储类信息、常量、静态变量等，JDK 8后被元空间（MetaSpace）替代；程序计数器（Program Counter Register），记录当前线程执行字节码的行号；虚拟机栈（Java Virtual Machine Stack），每个线程私有，存储局部变量表、操作数栈等；本地方法栈（Native Method Stack），为Native方法服务。各区域分工明确，共同保障Java程序的内存管理与运行。 2. 类加载过程，字节码加载过程：类加载过程分为加载、验证、准备、解析和初始化五个阶段。加载阶段负责通过类的全限定名获取字节码二进制流，并创建Class对象；验证阶段校验字节码文件的安全性和合法性；准备阶段为类变量分配内存并设置初始值；解析阶段将符号引用转为直接引用；初始化阶段执行类构造器 <clinit>() 方法，初始化静态变量和执行静态代码块。字节码加载属于加载阶段，通过类加载器（启动类加载器、扩展类加载器、应用程序类加载器）按双亲委派模型从文件系统、网络等途径获取字节码，确保类加载的安全性与唯一性 。</clinit>