很多人都有一个疑问，不知道如何在拿到 offer 之后跟 hr 谈薪资。其实谈薪资最重要的是积攒筹码，那什么是筹码呢？就是你手上的 offer。如果你拿到了好几个 offer，那已经说明你在市场上被多家公司认可了，这时候谈薪的时候，你会更优势的，而且成功率也会更大一些。比如你手上拿了 1 个 20k offer，跟下一家谈的时候，就可以喊 23k 的期望薪资，当然还是需要表达一下，你更想加入这家公司。那么，我们来看看 25 届阿里云开发岗的校招薪资情况如下：32k * 16 + 8w 签字费，同学背景硕士 985，城市北京30k * 16 + 5w 签字费，同学背景硕士 985，城市杭州28k * 16 + 5w 签字费，同学背景硕士 985，城市北京27k * 16，同学背景硕士海龟，城市杭州25k * 16，同学背景硕士985，城市北京整体年包在 40w-60w，还是非常具有竞争力的，除了薪资之外，还会还有交通补贴和餐补，而且杭州还会有政府的人才补贴。这次跟大家分享一下阿里云Java 后端的校招面经，这个是电话一面，主要是以拷打技术基础为主，主要是考察了MySQL+Java+Redis+Linux 的知识，由于是电话面，最后是口述算法逻辑。阿里云面经具体的面试问题如下，大家觉得难得如何呢？【技术大厂，前后端/测试捞人机会，待遇还不错，感兴趣可以试试】MySQL事务隔离级别有哪些？读未提交（read uncommitted），指一个事务还没提交时，它做的变更就能被其他事务看到；读提交（read committed），指一个事务提交之后，它做的变更才能被其他事务看到；可重复读（repeatable read），指一个事务执行过程中看到的数据，一直跟这个事务启动时看到的数据是一致的，MySQL InnoDB 引擎的默认隔离级别；串行化（serializable）；会对记录加上读写锁，在多个事务对这条记录进行读写操作时，如果发生了读写冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行；按隔离水平高低排序如下：img针对不同的隔离级别，并发事务时可能发生的现象也会不同。也就是说：在「读未提交」隔离级别下，可能发生脏读、不可重复读和幻读现象；在「读提交」隔离级别下，可能发生不可重复读和幻读现象，但是不可能发生脏读现象；在「可重复读」隔离级别下，可能发生幻读现象，但是不可能脏读和不可重复读现象；在「串行化」隔离级别下，脏读、不可重复读和幻读现象都不可能会发生。幻读和脏读的区别？脏读如果一个事务「读到」了另一个「未提交事务修改过的数据」，就意味着发生了「脏读」现象。举个栗子。假设有 A 和 B 这两个事务同时在处理，事务 A 先开始从数据库中读取小林的余额数据，然后再执行更新操作，如果此时事务 A 还没有提交事务，而此时正好事务 B 也从数据库中读取小林的余额数据，那么事务 B 读取到的余额数据是刚才事务 A 更新后的数据，即使没有提交事务。img因为事务 A 是还没提交事务的，也就是它随时可能发生回滚操作，如果在上面这种情况事务 A 发生了回滚，那么事务 B 刚才得到的数据就是过期的数据，这种现象就被称为脏读。幻读在一个事务内多次查询某个符合查询条件的「记录数量」，如果出现前后两次查询到的记录数量不一样的情况，就意味着发生了「幻读」现象。举个栗子。假设有 A 和 B 这两个事务同时在处理，事务 A 先开始从数据库查询账户余额大于 100 万的记录，发现共有 5 条，然后事务 B 也按相同的搜索条件也是查询出了 5 条记录。img接下来，事务 A 插入了一条余额超过 100 万的账号，并提交了事务，此时数据库超过 100 万余额的账号个数就变为 6。然后事务 B 再次查询账户余额大于 100 万的记录，此时查询到的记录数量有 6 条，发现和前一次读到的记录数量不一样了，就感觉发生了幻觉一样，这种现象就被称为幻读。如何防止幻读？MySQL InnoDB 引擎的默认隔离级别虽然是「可重复读」，但是它很大程度上避免幻读现象（并不是完全解决了），解决的方案有两种：针对快照读（普通 select 语句），是通过 MVCC 方式解决了幻读，因为可重复读隔离级别下，事务执行过程中看到的数据，一直跟这个事务启动时看到的数据是一致的，即使中途有其他事务插入了一条数据，是查询不出来这条数据的，所以就很好了避免幻读问题。针对当前读（select ... for update 等语句），是通过 next-key lock（记录锁+间隙锁）方式解决了幻读，因为当执行 select ... for update 语句的时候，会加上 next-key lock，如果有其他事务在 next-key lock 锁范围内插入了一条记录，那么这个插入语句就会被阻塞，无法成功插入，所以就很好了避免幻读问题。事务的mvcc机制原理是什么？MVCC允许多个事务同时读取同一行数据，而不会彼此阻塞，每个事务看到的数据版本是该事务开始时的数据版本。这意味着，如果其他事务在此期间修改了数据，正在运行的事务仍然看到的是它开始时的数据状态，从而实现了非阻塞读操作。对于「读提交」和「可重复读」隔离级别的事务来说，它们是通过 Read View 来实现的，它们的区别在于创建 Read View 的时机不同，大家可以把 Read View 理解成一个数据快照，就像相机拍照那样，定格某一时刻的风景。「读提交」隔离级别是在「每个select语句执行前」都会重新生成一个 Read View；「可重复读」隔离级别是执行第一条select时，生成一个 Read View，然后整个事务期间都在用这个 Read View。Read View 有四个重要的字段：imgm_ids ：指的是在创建 Read View 时，当前数据库中「活跃事务」的事务 id 列表，注意是一个列表，“活跃事务”指的就是，启动了但还没提交的事务。min_trx_id ：指的是在创建 Read View 时，当前数据库中「活跃事务」中事务 id 最小的事务，也就是 m_ids 的最小值。max_trx_id ：这个并不是 m_ids 的最大值，而是创建 Read View 时当前数据库中应该给下一个事务的 id 值，也就是全局事务中最大的事务 id 值 + 1；creator_trx_id ：指的是创建该 Read View 的事务的事务 id。对于使用 InnoDB 存储引擎的数据库表，它的聚簇索引记录中都包含下面两个隐藏列：imgtrx_id，当一个事务对某条聚簇索引记录进行改动时，就会把该事务的事务 id 记录在 trx_id 隐藏列里；roll_pointer，每次对某条聚簇索引记录进行改动时，都会把旧版本的记录写入到 undo 日志中，然后这个隐藏列是个指针，指向每一个旧版本记录，于是就可以通过它找到修改前的记录。在创建 Read View 后，我们可以将记录中的 trx_id 划分这三种情况：img一个事务去访问记录的时候，除了自己的更新记录总是可见之外，还有这几种情况：如果记录的 trx_id 值小于 Read View 中的 min_trx_id 值，表示这个版本的记录是在创建 Read View 前已经提交的事务生成的，所以该版本的记录对当前事务可见。如果记录的 trx_id 值大于等于 Read View 中的 max_trx_id 值，表示这个版本的记录是在创建 Read View 后才启动的事务生成的，所以该版本的记录对当前事务不可见。如果记录的 trx_id 值在 Read View 的 min_trx_id 和 max_trx_id 之间，需要判断 trx_id 是否在 m_ids 列表中：如果记录的 trx_id 在 m_ids 列表中，表示生成该版本记录的活跃事务依然活跃着（还没提交事务），所以该版本的记录对当前事务不可见。如果记录的 trx_id 不在 m_ids列表中，表示生成该版本记录的活跃事务已经被提交，所以该版本的记录对当前事务可见。这种通过「版本链」来控制并发事务访问同一个记录时的行为就叫 MVCC（多版本并发控制）。mysql的什么命令会加上间隙锁？在可重复读隔离级别下。当你使用非唯一索引进行查询时，InnoDB可能会在索引间隙上加上间隙锁，例如 SELECT * FROM t WHERE a = ? FOR UPDATE; 如果a是非唯一索引，MySQL会在该值的前后加上间隙锁，以防止其他事务在这些间隙插入新记录。在执行带有WHERE条件的DELETE语句时，如果使用的是非唯一索引，MySQL会在符合条件的记录的前后加上间隙锁。类似地，在执行带有WHERE条件的UPDATE语句时，如果使用的是非唯一索引，MySQL也会在符合条件的记录的前后加上间隙锁。Java双亲委派机制是什么？双亲委派机制是Java类加载器（ClassLoader）中的一种工作原理。它主要用于解决类加载过程中的安全和避免重复加载的问题。在这个机制中，类加载器之间存在层次关系，每个类加载器都有一个父加载器。当一个类需要被加载时，加载请求会从当前加载器开始，逐级向上委托给父加载器，直到根加载器（Bootstrap ClassLoader）。如果根加载器无法加载该类，那么委托链上的每个加载器都会尝试加载，直到找到合适的加载器或者无法加载为止。双亲委派机制的好处：保证类的唯一性：通过委托机制，确保了所有加载请求都会传递到启动类加载器，避免了不同类加载器重复加载相同类的情况，保证了Java核心类库的统一性，也防止了用户自定义类覆盖核心类库的可能。保证安全性：由于Java核心库被启动类加载器加载，而启动类加载器只加载信任的类路径中的类，这样可以防止不可信的类假冒核心类，增强了系统的安全性。例如，恶意代码无法自定义一个java.lang.System类并加载到JVM中，因为这个请求会被委托给启动类加载器，而启动类加载器只会加载标准的Java库中的类。支持隔离和层次划分：双亲委派模型支持不同层次的类加载器服务于不同的类加载需求，如应用程序类加载器加载用户代码，扩展类加载器加载扩展框架，启动类加载器加载核心库。这种层次化的划分有助于实现沙箱安全机制，保证了各个层级类加载器的职责清晰，也便于维护和扩展。简化了加载流程：通过委派，大部分类能够被正确的类加载器加载，减少了每个加载器需要处理的类的数量，简化了类的加载过程，提高了加载效率。垃圾回收 cms和g1的区别是什么？区别一：使用的范围不一样：CMS收集器是老年代的收集器，可以配合新生代的Serial和ParNew收集器一起使用G1收集器收集范围是老年代和新生代。不需要结合其他收集器使用区别二：STW的时间：CMS收集器以最小的停顿时间为目标的收集器。G1收集器可预测垃圾回收的停顿时间（建立可预测的停顿时间模型）区别三： 垃圾碎片CMS收集器是使用“标记-清除”算法进行的垃圾回收，容易产生内存碎片G1收集器使用的是“标记-整理”算法，进行了空间整合，没有内存空间碎片。区别四： 垃圾回收的过程不一样注意这两个收集器第四阶段得不同区别五: CMS会产生浮动垃圾CMS产生浮动垃圾过多时会退化为serial old，效率低，因为在上图的第四阶段，CMS清除垃圾时是并发清除的，这个时候，垃圾回收线程和用户线程同时工作会产生浮动垃圾，也就意味着CMS垃圾回收器必须预留一部分内存空间用于存放浮动垃圾而G1没有浮动垃圾，G1的筛选回收是多个垃圾回收线程并行gc的，没有浮动垃圾的回收，在执行‘并发清理’步骤时，用户线程也会同时产生一部分可回收对象，但是这部分可回收对象只能在下次执行清理是才会被回收。如果在清理过程中预留给用户线程的内存不足就会出现‘Concurrent Mode Failure’,一旦出现此错误时便会切换到SerialOld收集方式。spring三级缓存解决循环依赖问题？循环依赖指的是两个类中的属性相互依赖对方：例如 A 类中有 B 属性，B 类中有 A属性，从而形成了一个依赖闭环，如下图。循环依赖问题在Spring中主要有三种情况：第一种：通过构造方法进行依赖注入时产生的循环依赖问题。第二种：通过setter方法进行依赖注入且是在多例（原型）模式下产生的循环依赖问题。第三种：通过setter方法进行依赖注入且是在单例模式下产生的循环依赖问题。只有【第三种方式】的循环依赖问题被 Spring 解决了，其他两种方式在遇到循环依赖问题时，Spring都会产生异常。Spring 解决单例模式下的setter循环依赖问题的主要方式是通过三级缓存解决循环依赖。三级缓存指的是 Spring 在创建 Bean 的过程中，通过三级缓存来缓存正在创建的 Bean，以及已经创建完成的 Bean 实例。具体步骤如下：实例化 Bean：Spring 在实例化 Bean 时，会先创建一个空的 Bean 对象，并将其放入一级缓存中。属性赋值：Spring 开始对 Bean 进行属性赋值，如果发现循环依赖，会将当前 Bean 对象提前暴露给后续需要依赖的 Bean（通过提前暴露的方式解决循环依赖）。初始化 Bean：完成属性赋值后，Spring 将 Bean 进行初始化，并将其放入二级缓存中。注入依赖：Spring 继续对 Bean 进行依赖注入，如果发现循环依赖，会从二级缓存中获取已经完成初始化的 Bean 实例。通过三级缓存的机制，Spring 能够在处理循环依赖时，确保及时暴露正在创建的 Bean 对象，并能够正确地注入已经初始化的 Bean 实例，从而解决循环依赖问题，保证应用程序的正常运行。如何使用spring实现事务？声明式事务管理使用@Transactional注解来管理事务比较简单，示例如下：@Servicepublic class TransactionDemo {​    @Transactional    public void declarativeUpdate() {        updateOperation1();        updateOperation2();    }}这样的写法相当于在进入declarativeUpdate()方法前，使用BEGIN开启了事务，在执行完方法后，使用COMMIT提交事务。也可以将@Transactional注解放在类上面，表示类中所有的public方法都开启了事务：@Service@Transactionalpublic class TransactionDemo {    public void declarativeUpdate() {        updateOperation1();        updateOperation2();    }    // 其他public方法...}编程式事务管理相比之下，使用编程式事务要略微复杂一些。编程式事务管理是通过编写代码来显式地管理事务。这种方式提供了更多的控制，但也会使业务代码变得复杂。Spring提供了TransactionTemplate类来简化编程式事务管理。import org.springframework.beans.factory.annotation.Autowired;import org.springframework.stereotype.Service;import org.springframework.transaction.PlatformTransactionManager;import org.springframework.transaction.TransactionStatus;import org.springframework.transaction.support.TransactionCallbackWithoutResult;import org.springframework.transaction.support.TransactionTemplate;​@Servicepublic class UserService {​    @Autowired    private UserDao userDao;​    @Autowired    private TransactionTemplate transactionTemplate;​    public void addUser(User user) {        transactionTemplate.execute(new TransactionCallbackWithoutResult() {            @Override            protected void doInTransactionWithoutResult(TransactionStatus status) {                userDao.insert(user);                // 其他数据库操作            }        });    }}声明式事务 vs 编程式事务在合适的场景使用合适的方式非常重要，在一些场景下，当对事务操作非常频繁，特别是在递归、外部通讯等耗时的场景中使用事务，很有可能就会引发长事务，那么应该考虑将非事务的部分放在前面执行，最后在写入数据环节时再开启事务。介绍事务传播模型有哪些？Spring中规定了7种类型的事务传播特性：springboot常用注解有哪些？Bean 相关：@Component：将一个类标识为 Spring 组件（Bean），可以被 Spring 容器自动检测和注册。通用注解，适用于任何层次的组件。@ComponentScan：自动扫描指定包及其子包中的 Spring 组件。@Controller：标识控制层组件，实际上是 @Component 的一个特化，用于表示 Web 控制器。处理 HTTP 请求并返回视图或响应数据。@RestController：是 @Controller 和 @ResponseBody 的结合，返回的对象会自动序列化为 JSON 或 XML，并写入 HTTP 响应体中。@Repository：标识持久层组件（DAO 层），实际上是 @Component 的一个特化，用于表示数据访问组件。常用于与数据库交互。@Bean：方法注解，用于修饰方法，主要功能是将修饰方法的返回对象添加到 Spring 容器中，使得其他组件可以通过依赖注入的方式使用这个对象。依赖注入：@Autowired：用于自动注入依赖对象，Spring 框架提供的注解。@Resource：按名称自动注入依赖对象（也可以按类型，但默认按名称），JDK 提供注解。@Qualifier：与 @Autowired 一起使用，用于指定要注入的 Bean 的名称。当存在多个相同类型的 Bean 时，可以使用 @Qualifier 来指定注入哪一个。读取配置：@Value：用于注入属性值，通常从配置文件中获取。标注在字段上，并指定属性值的来源（如配置文件中的某个属性）。@ConfigurationProperties：用于将配置属性绑定到一个实体类上。通常用于从配置文件中读取属性值并绑定到类的字段上。Web相关：@RequestMapping：用于映射 HTTP 请求到处理方法上，支持 GET、POST、PUT、DELETE 等请求方法。可以标注在类或方法上。标注在类上时，表示类中的所有响应请求的方法都是以该类路径为父路径。@GetMapping、@PostMapping、@PutMapping、@DeleteMapping：分别用于映射 HTTP GET、POST、PUT、DELETE 请求到处理方法上。它们是 @RequestMapping 的特化，分别对应不同的 HTTP 请求方法。其他常用注解：@Transactional：声明事务管理。标注在类或方法上，指定事务的传播行为、隔离级别等。@Scheduled：声明一个方法需要定时执行。标注在方法上，并指定定时执行的规则（如每隔一定时间执行一次）。介绍NIO BIO AIO？BIO（blocking IO）：就是传统的 java.io 包，它是基于流模型实现的，交互的方式是同步、阻塞方式，也就是说在读入输入流或者输出流时，在读写动作完成之前，线程会一直阻塞在那里，它们之间的调用是可靠的线性顺序。优点是代码比较简单、直观；缺点是 IO 的效率和扩展性很低，容易成为应用性能瓶颈。NIO（non-blocking IO） ：Java 1.4 引入的 java.nio 包，提供了 Channel、Selector、Buffer 等新的抽象，可以构建多路复用的、同步非阻塞 IO 程序，同时提供了更接近操作系统底层高性能的数据操作方式。AIO（Asynchronous IO） ：是 Java 1.7 之后引入的包，是 NIO 的升级版本，提供了异步非堵塞的 IO 操作方式，所以人们叫它 AIO（Asynchronous IO），异步 IO 是基于事件和回调机制实现的，也就是应用操作之后会直接返回，不会堵塞在那里，当后台处理完成，操作系统会通知相应的线程进行后续的操作。Redisredis高级数据结构的使用场景Redis 提供了丰富的数据类型，常见的有五种数据类型：String（字符串），Hash（哈希），List（列表），Set（集合）、Zset（有序集合）。随着 Redis 版本的更新，后面又支持了四种数据类型：BitMap（2.2 版新增）、HyperLogLog（2.8 版新增）、GEO（3.2 版新增）、Stream（5.0 版新增）。Redis 五种数据类型的应用场景：String 类型的应用场景：缓存对象、常规计数、分布式锁、共享 session 信息等。List 类型的应用场景：消息队列（但是有两个问题：1. 生产者需要自行实现全局唯一 ID；2. 不能以消费组形式消费数据）等。Hash 类型：缓存对象、购物车等。Set 类型：聚合计算（并集、交集、差集）场景，比如点赞、共同关注、抽奖活动等。Zset 类型：排序场景，比如排行榜、电话和姓名排序等。Redis 后续版本又支持四种数据类型，它们的应用场景如下：BitMap（2.2 版新增）：二值状态统计的场景，比如签到、判断用户登陆状态、连续签到用户总数等；HyperLogLog（2.8 版新增）：海量数据基数统计的场景，比如百万级网页 UV 计数等；GEO（3.2 版新增）：存储地理位置信息的场景，比如滴滴叫车；Stream（5.0 版新增）：消息队列，相比于基于 List 类型实现的消息队列，有这两个特有的特性：自动生成全局唯一消息ID，支持以消费组形式消费数据。linuxlinux常用命令有哪些？文件相关(mv mkdir cd ls)进程相关( ps top netstate )权限相关(chmod chown useradd groupadd)网络相关(netstat ip addr)测试相关(测试网络连通性:ping 测试端口连通性:telnet)kill -9 9的意义是什么，如何做到强制终止线程kill -9 是一个Linux/Unix系统中的命令，用于向进程发送信号。-9代表的是SIGKILL信号，这是一种无法被捕获、忽略或重定义的信号，用于立即终止一个进程。当使用kill -9命令时，操作系统会立即停止目标进程，不会给进程任何清理或释放资源的机会。kill命令是针对进程的，而不是针对线程的。要终止一个线程，你需要知道该线程所属的进程ID（PID）和线程ID（TID）。以下是几种终止线程的方法：使用kill命令终止整个进程：如果你想要终止包含特定线程的整个进程，可以使用kill命令发送SIGKILL信号给进程。kill -9 <PID>使用kill命令结合ps和grep命令查找线程ID：如果你只知道线程的名称或某些特征，可以使用ps和grep命令来查找线程ID，然后使用kill命令终止线程。ps -eLf | grep <thread_name_or_feature> | grep -v grep | awk '{print $2}' | xargs kill -9这里的<thread_name_or_feature>是线程的名称或某些特征。转载于：小林coding