月初旁观了同门的研二开题情况，说实话，还是有些焦虑的。我是研一，同门研二4人，毕业要求基本是有篇水刊校报就行，但研二4人中只有1位有小论文，顺利开题，另外3位岌岌可危。我学院强制末尾10%二次开题，并且上一届延毕率40/180，延毕的达摩克里斯之剑悬在每个人头上。研三的师兄师姐基本都是靠发校报毕业，可以说磕磕绊绊研二的1位有小论文顺利开题，1位年初听老师安排换了方向，另外2位自己摸索，也没成果，结果就是要二次答辩，还是挺烦恼的。结合自身情况，身边27届的同学找实习遇阻（大多岗位更倾向于26应届）自己学的时间也不够，所以就临时放一放Java学习，转向了科研任务。自己的预期是：4、5月份做实验，想...

小厂面经，也是我的处女面（30min）1.自我介绍2.spring boot的自动装配原理（好多类和接口的单词都忘了全称是啥了，就说了记得的单词，流程应该说对了吧）3.有用过redis吗？主要是用在实现什么功能（说了技术派用redis的zset来实现排行榜）5.有了解过Redisson吗？讲一下对于分布式锁的了解以及在什么场景下应用（说了秒杀场景）6.对mysql有了解吗？包括它的索引优化和创建（把想起来的全说了）7.了解设计模式吗？比如单例模式，为什么要使用单例模式，它的优点是什么（昨天刚看的设计模式）8.工厂模式有了解吗？主要的使用场景是？（也是昨天刚看的）9.场景题：有7个服务器，需要在早上十点定时的向数据库中的用户表中的用户发短信，如果做到发送的消息不重复，且如果发送失败了需要知道是到哪个用户失败了，这样下次就直接从这个用户开始（我答了用spring task来实现定时，用分布式锁来保证只有一份服务器可以发送消息，用消息队列来存储消息，然后用消息确认机制来保证错误信息的记录，以及在数据库或者业务层面完成消息消费的幂等性）10.场景题：如果在系统启动的时间就将数据库的所有用户相关的信息都读到一个hashmap中（这个没啥思路，没答好）27届的投了一个星期终于有一个面试了，大部分公司都只招26的

MSOL数据库死锁问题比较常见，接下来通过一个死锁排查过程的例子给大家讲解。这个例子将模拟一个实际的死锁场景,然后一步步展示如何识别、分析和解决这个死锁问题场景描述假设我们有一个在线商店系统,包含以下两个表:1.products(产品表)2.orders(订单表)两个并发事务试图更新这些表,导致了死锁。步骤1: 复现死锁首先,我们需要创建一个能够可靠复现死锁的场暴。 --创建表 CREATE TABLE products( id INT PRIMARY KEY, name VARCHAR(100), stock INT ); CREATE TABLE orders( id INT ...