图解学习网站：

大家好，我是小林。

转眼八月的夏天就这么过去了，步入 9 月份了，接下来秋招会进入高峰时期，已经准备差不多的同学，建议 9 月份中旬之前就要把简历投出去了。

简历投出去也不是马上就能面试的，内部审核+笔试这些流程，可能都要 1-2 周的时间，所以即使投出去了，还是有时间继续准备面试的。

8 月份基本是互联网中大厂批量开启了秋招，那到了 9 月份，国企/银行这类企业就会扎堆扎堆的开启秋招了，想冲国企/银行的同学，可以做好投递的准备了。

就比如看到「招商银行」已经率先开启银行了，注意不是招银网络科技。

我翻了一下招商银行秋招开发相关的岗位，还是有不少的，软件开发、系统开发、数据分析、后端开发都是有的。

上面写着投递时间 10月10日 截止，想赶第一批秋招的，可以直接开始投了。

之前也有很多同学问过我，没有英语六级影响找开发岗位吗？

这个其实主要看公司，比如互联网公司，基本没有硬性要求的，甚至我都见过没有英语四级的同学也直接进了一线大厂的，因为工作根本就没有英文交流的需求，自然对这方面就不是很看重的。

当然像外企公司，因为工作可能会和外国友人交流，可能对英文还是有要求的，甚至有面试都需要全英文。

那国企和银行这些企业要求英语四六级吗？我看了招商银行后端开发的岗位需求，发现对英语证书是有要求，本科生一定要有四级，研究生则需要六级。

具体每个公司的需求，还是看具体公司的要求了，并不是每个公司的规则都是要求的。

很早之前也有有同学拿到招商银行的实习，他学的是Go后端，面的是Java岗位实习，从这个角度来看的话，说明即使语言不是匹配的，也是有机会面进银行的，因为后端技术栈都是通用的。

后面我也是建议同学去银行实习了，沉淀一段实习经历，对校招而言都是是很加分的，因为开发岗位本身就是比较看重一个开发工程经验，那怎么能体现你的开发工程经验呢？无非就是实习经历+项目经历了。

那么既然招商银行秋招来了，给大伙们来一篇去年招商银行秋招Java一面，部门是银行信用卡中心。

即使是银行技术面试，也是逃不了八股拷打一番，比如这场面经，JVM、Spring、MySQL、消息队列这些八股都拷打一番，可能相比互联网公司的面试，就是面试中没有强制要手撕算法，你们觉得难度如何呢？

招商银行（Java一面）1. JVM内存结构有哪些？

根据 JDK 8 规范，JVM 运行时内存共分为虚拟机栈、堆、元空间、程序计数器、本地方法栈五个部分。还有一部分内存叫直接内存，属于操作系统的本地内存，也是可以直接操作的。

JVM的内存结构主要分为以下几个部分：

• 程序计数器：可以看作是当前线程所执行的字节码的行号指示器，用于存储当前线程正在执行的 Java 方法的 JVM 指令地址。如果线程执行的是 Native 方法，计数器值为 null。是唯一一个在 Java 虚拟机规范中没有规定任何 OutOfMemoryError 情况的区域，生命周期与线程相同。

• Java 虚拟机栈：每个线程都有自己独立的 Java 虚拟机栈，生命周期与线程相同。每个方法在执行时都会创建一个栈帧，用于存储局部变量表、操作数栈、动态链接、方法出口等信息。可能会抛出 StackOverflowError 和 OutOfMemoryError 异常。

• 本地方法栈：与 Java 虚拟机栈类似，主要为虚拟机使用到的 Native 方法服务，在 HotSpot 虚拟机中和 Java 虚拟机栈合二为一。本地方法执行时也会创建栈帧，同样可能出现 StackOverflowError 和 OutOfMemoryError 两种错误。

• Java 堆：是 JVM 中最大的一块内存区域，被所有线程共享，在虚拟机启动时创建，用于存放对象实例。从内存回收角度，堆被划分为新生代和老年代，新生代又分为 Eden 区和两个 Survivor 区（From Survivor 和 To Survivor）。如果在堆中没有内存完成实例分配，并且堆也无法扩展时会抛出 OutOfMemoryError 异常。

• 方法区（元空间）：在 JDK 1.8 及以后的版本中，方法区被元空间取代，使用本地内存。用于存储已被虚拟机加载的类信息、常量、静态变量等数据。虽然方法区被描述为堆的逻辑部分，但有 “非堆” 的别名。方法区可以选择不实现垃圾收集，内存不足时会抛出 OutOfMemoryError 异常。

• 运行时常量池：是方法区的一部分，用于存放编译期生成的各种字面量和符号引用，具有动态性，运行时也可将新的常量放入池中。当无法申请到足够内存时，会抛出 OutOfMemoryError 异常。

• 直接内存：不属于 JVM 运行时数据区的一部分，通过 NIO 类引入，是一种堆外内存，可以显著提高 I/O 性能。直接内存的使用受到本机总内存的限制，若分配不当，可能导致 OutOfMemoryError 异常。

• 堆内存不足：当堆中剩余空间不足以容纳新对象，且 JVM 无法通过垃圾回收释放足够内存时，会抛出OutOfMemoryError: Java heap space。这是最常见的情况，可能由对象创建速度远快于垃圾回收速度、内存泄漏（对象长期被无用引用持有）等导致。

• 堆内存分配策略限制：若 JVM 通过参数（如-Xmx设置最大堆内存、-XX:NewSize/-XX:MaxNewSize限制新生代大小）限制了堆的最大容量，且新对象需要的内存超过剩余可用空间，即使触发 Full GC 也无法释放足够内存，会导致分配失败。

• 大对象直接分配失败：某些 JVM 会将超过一定大小的对象直接分配到老年代，若老年代剩余空间不足且无法通过 Full GC 释放，会导致大对象分配失败。

• 内存碎片化：长期频繁的对象创建与回收可能导致堆内存碎片化，虽然总剩余内存足够，但没有连续的内存块容纳新对象（尤其是大对象），会导致分配失败。

双亲委派模型是 Java 类加载机制中重要的类加载双亲委派原则，其核心思想是一个类加载器在尝试加载某个类时，会先委托给其父类加载器进行加载，只有当父类加载器无法加载该类时，才由自身尝试加载。

具体工作流程，Java 中的类加载器存在固定的父子层级关系，常见的类加载器（从父到子）包括：

• 启动类加载器（Bootstrap ClassLoader）：最顶层，负责加载JAVA_HOME/lib目录下的核心类库（如rt.jar），由 C++ 实现。

• 扩展类加载器（Extension ClassLoader）：加载JAVA_HOME/lib/ext目录下的扩展类库。

• 应用程序类加载器（Application ClassLoader）：加载用户类路径（classpath）上的类，是程序默认的类加载器。

• 自定义类加载器：用户可通过继承ClassLoader实现，用于加载特定路径的类。

当某个类加载器（如自定义类加载器）需要加载类时，首先委托给其父类加载器（如应用程序类加载器）。父类加载器再向上委托给更上层的类加载器（如扩展类加载器），直至最顶层的启动类加载器。

若父类加载器能成功加载该类，则返回加载结果；若所有父类加载器都无法加载，才由最初的类加载器尝试自己加载。

所以双亲委派模型作用是：

• 保证类的唯一性：避免同一个类被不同类加载器重复加载，确保内存中只有一个类的 Class 对象（类的唯一性由类加载器和类名共同决定）。

• 防止核心类篡改：确保 Java 核心类库（如java.lang.String）不会被用户自定义的同名类替代，避免恶意代码对核心库的篡改，保障安全。

虽然双亲委派是默认机制，但某些场景下需要打破，例如：

• SPI 机制（如 JDBC）：Driver 接口由启动类加载器加载，但具体实现类（如 MySQL 驱动）在 classpath 下，需由应用类加载器加载，此时会通过线程上下文类加载器突破委派。

• 热部署：动态替换已加载的类，需要自定义类加载器绕过双亲委派。

• 解耦：可以在多个系统之间进行解耦，将原本通过网络之间的调用的方式改为使用MQ进行消息的异步通讯，只要该操作不是需要同步的，就可以改为使用MQ进行不同系统之间的联系，这样项目之间不会存在耦合，系统之间不会产生太大的影响，就算一个系统挂了，也只是消息挤压在MQ里面没人进行消费而已，不会对其他的系统产生影响。

• 异步：加入一个操作设计到好几个步骤，这些步骤之间不需要同步完成，比如客户去创建了一个订单，还要去客户轨迹系统添加一条轨迹、去库存系统更新库存、去客户系统修改客户的状态等等。这样如果这个系统都直接进行调用，那么将会产生大量的时间，这样对于客户是无法接收的；并且像添加客户轨迹这种操作是不需要去同步操作的，如果使用MQ将客户创建订单时，将后面的轨迹、库存、状态等信息的更新全都放到MQ里面然后去异步操作，这样就可加快系统的访问速度，提供更好的客户体验。

• 削峰：一个系统访问流量有高峰时期，也有低峰时期，比如说，中午整点有一个抢购活动等等。比如系统平时流量并不高，一秒钟只有100多个并发请求，系统处理没有任何压力，一切风平浪静，到了某个抢购活动时间，系统并发访问了剧增，比如达到了每秒5000个并发请求，而我们的系统每秒只能处理2000个请求，那么由于流量太大，我们的系统、数据库可能就会崩溃。这时如果使用MQ进行流量削峰，将用户的大量消息直接放到MQ里面，然后我们的系统去按自己的最大消费能力去消费这些消息，就可以保证系统的稳定，只是可能要跟进业务逻辑，给用户返回特定页面或者稍后通过其他方式通知其结果

使用一个消息队列，其实就分为三大块：生产者、中间件、消费者，所以要保证消息就是保证三个环节都不能丢失数据。

• 消息生产阶段：生产者会不会丢消息，取决于生产者对于异常情况的处理是否合理。从消息被生产出来，然后提交给 MQ 的过程中，只要能正常收到 （ MQ 中间件） 的 ack 确认响应，就表示发送成功，所以只要处理好返回值和异常，如果返回异常则进行消息重发，那么这个阶段是不会出现消息丢失的。

• 消息存储阶段：Kafka 在使用时是部署一个集群，生产者在发布消息时，队列中间件通常会写「多个节点」，也就是有多个副本，这样一来，即便其中一个节点挂了，也能保证集群的数据不丢失。

• 消息消费阶段：消费者接收消息+消息处理之后，才回复 ack 的话，那么消息阶段的消息不会丢失。不能收到消息就回 ack，否则可能消息处理中途挂掉了，消息就丢失了。

幂等性是指 同一操作的多次执行对系统状态的影响与一次执行结果一致。例如，支付接口若因网络重试被多次调用，最终应确保仅扣款一次。实现幂等写的核心方案：

• 唯一标识（幂等键）：客户端为每个请求生成全局唯一ID（如 UUID、业务主键），服务端校验该ID是否已处理，适用场景接口调用、消息消费等。

• 数据库事务 + 乐观锁：通过版本号或状态字段控制并发更新，确保多次更新等同于单次操作，适用场景数据库记录更新（如余额扣减、订单状态变更）。

• 数据库唯一约束：利用数据库唯一索引防止重复数据写入，适用场景数据插入场景（如订单创建）。

• 分布式锁：通过锁机制保证同一时刻仅有一个请求执行关键操作，适用场景高并发下的资源抢夺（如秒杀）。

• 消息去重：消息队列生产者为每条消息生成唯一的消息 ID，消费者在处理消息前，先检查该消息 ID 是否已经处理过，如果已经处理过则丢弃该消息。

Spring AOP的实现依赖于动态代理技术。动态代理是在运行时动态生成代理对象，而不是在编译时。它允许开发者在运行时指定要代理的接口和行为，从而实现在不修改源码的情况下增强方法的功能。

Spring AOP支持两种动态代理：

• 基于JDK的动态代理：使用java.lang.reflect.Proxy类和java.lang.reflect.InvocationHandler接口实现。这种方式需要代理的类实现一个或多个接口。

• 基于CGLIB的动态代理：当被代理的类没有实现接口时，Spring会使用CGLIB库生成一个被代理类的子类作为代理。CGLIB是一个第三方代码生成库，通过继承方式实现代理。

常用的注解包括：

• @Aspect：用于定义切面，标注在切面类上。

• @Pointcut：定义切点，标注在方法上，用于指定连接点。

• @Before：在方法执行之前执行通知。

• @After：在方法执行之后执行通知。

• @Around：在方法执行前后都执行通知。

• @AfterReturning：在方法执行后返回结果后执行通知。

• @AfterThrowing：在方法抛出异常后执行通知。

• @Advice：通用的通知类型，可以替代@Before、@After等。

• CHAR是固定长度的字符串类型，定义时需要指定固定长度，存储时会在末尾补足空格。CHAR适合存储长度固定的数据，如固定长度的代码、状态等，存储空间固定，对于短字符串效率较高。

• VARCHAR是可变长度的字符串类型，定义时需要指定最大长度，实际存储时根据实际长度占用存储空间。VARCHAR适合存储长度可变的数据，如用户输入的文本、备注等，节约存储空间。

一行记录最大能存储 65535 字节的数据，但是这个是包含「变长字段字节数列表所占用的字节数」和「NULL值列表所占用的字节数」。

所以，我们在算 varchar(n) 中n最大值时，需要减去这两个列表所占用的字节数。

如果一张表只有一个 varchar(n) 字段，且允许为 NULL，字符集为 ascii。varchar(n) 中n最大取值为65532。

计算公式:65535-变长字段字节数列表所占用的字节数-NULL值列表所占用的字节数=65535-2-1=65532

如果有多个字段的话，要保证所有字段的长度+变长字段字节数列表所占用的字节数+NULL值列表所占用的字节数<=65535。