谁说这铜11晚啊，这铜11可太棒了！

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

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

公司地址在一个小区里

刷到一篇推文，深有共鸣，以前对各种上岸的焦虑就像密集的细针扎入身体，造成隐蔽的伤害与持久的麻木，总会想上了大学就好了，考上研究生就好了，毕业找到工作就好了，结婚孩子长大就好了，因为这些外界强加的目标，导致在目标完成前的生活总像是一种“暂时态”，因为是暂时状态，所以很自然地认为凑合凑合过得去就行，但以后的一天是一天，现在的一天也是一天，并且以后是无法掌控的，那不如过好当下的每一分每一秒。在家里，一切的一切都在治愈我，咖啡浓郁的焦香占据鼻腔，用独门秘技加入牛奶得到世界上独一无二的豪放派拉花，宫廷玉液咖，一百八一杯；和妈妈一起买菜，走出超市看见落日正西沉，照得世界金光一片；一家人开很久的车去吃新菜品...