ITPub博客

反应式编程在好几年前就已经出现了，它原理是基于反应式编宣言。但是，由于反应式编程推广速度比较缓慢，导致很多人现在对其不是很了解。

我们很多人都以为CodeReview不重要，因为其他人写的代码和自己的关系可能不是太大，review的时候也不会上心，但事实上这个想法大错特错。CodeReview和我们的日常开发息息相关，缺少了它，那你的项目就是不完整的了。 本文作者Yezhiwei，我做了一些适当补充。

在之前的文章中已经介绍过Seata的总体介绍，如何使用以及Seata-Server的原理分析，有兴趣的可以阅读下面的文章：深度剖析一站式分布式事务方案Seata-Server，解密分布式事务框架-Fescar，这篇文章会介绍Seata中另外两个重要的角色TM(事务管理器)和RM(资源管理器)，

我曾经写过一篇和本文标题类似的文章《研究优雅停机时的一点思考》，上文和本文都有一个共同点：网卡地址注册和优雅停机都是一个很小的知识点，但是背后牵扯到的知识点却是庞大的体系，我在写这类文章前基本也和大多数读者一样，处于“知道有这么个东西，但不了解细节”的阶段，但一旦深挖，会感受到其中的奇妙，并有机会接触到很多平时不太关注的知识点。

再前不久，我写了一篇关于分布式事务中间件Fescar的解析，没过几天Fescar团队对其进行了品牌升级，取名为Seata(Simpe Extensible Autonomous Transcaction Architecture)，而以前的Fescar的英文全称为Fast & EaSy Commit And Rollback。可以看见Fescar从名字上来看更加局限于Commit和Rollback，而新的品牌名字Seata旨在打造一套一站式分布式事务解决方案。更换名字之后，我对其未来的发展更有信心。

3 月 8 号是国际劳动妇女节，漫威在这天“搞事”了。上映《惊奇队长》，这部是漫威电影宇宙的第一部女性超级英雄电影，也算是给妇女节献礼。身为漫威粉丝的我，当时不会错过这部电影，趁着周末去观影。

记得那是一个风和日丽的周末，太阳红彤彤，花儿五颜六色，96 年的普哥微信找到我，描述了一个诡异的线上问题：线上程序使用了 NIO FileChannel 的 堆内内存作为缓冲区，读写文件，逻辑可以说相当简单，但根据监控却发现堆外内存飙升，导致了 OutOfMemeory 的异常。

之前和crossoverJie一起排查了一个线上问题，他将其总结了一下，这里我做下转发。这个问题其实是因为一些编码的规范和对一些新的框架的不熟悉造成的，整个排查过程大家可以学习一下。

某一天在某一个群里面的某个群友突然提出了一个问题:"threadlocal的key是弱引用，那么在threadlocal.get()的时候,发生GC之后，key是否是null？"屏幕前的你可以好好的想想这个问题，在这里我先卖个关子，先讲讲Java中引用和ThreadLocal的那些事。

说起Mysql死锁，之前写过一次有关Mysql加锁的基本介绍，对于一些基本的Mysql锁或者死锁都有一个简单的认识，可以看下这篇文章为什么开发人员需要了解分布式锁。有了上面的经验之后，本以为对于死锁都能手到擒来，没想到再一个阳光明媚的下午报出了一个死锁，但是这一次却没想象的那么简单。