消息队列解析(2)-MQ选型 1 选型标准 1.1 开源（白嫖） 方便修改源码，而非阻塞等待软件提供商猴年马月发布下个版本解决。 1.2 生态（大家一起玩） 方便找到很多问题的解决方案，和主流框架也无缝对接。 1.3 确保消息可靠传递 1.4 Cluster 高可用性。 1.5 性能 具备足够好的性能，能满足绝大多数场景的性能要求。 于是市面上主要就如下可供选择： 2 RabbitMQ 2.1 优点 Erlang编写，最早为电信行业系统可靠通信设计，是支持AMQP协议的消息队列之一。相当轻量级的消息队列，非常容易部署和使用。号称世上使用最广泛的开源MQ。 灵活的路由配置 和其他MQ不同，它在生...

每条SQL语句，MySQL都会经过成本和规则的优化，对这个SQL选择对应的一些访问方法和顺序，包括做一些特殊的改写确保执行效率是最优的，然后优化过后，就会得到一个执 行计划。 执行计划，落实到底层，无非就是先访问哪个表，用哪个索引还是全表扫描，拿到数据后如何回表，是否要基于临时磁盘文件做分组聚合或者排序。 简单的单表查询，可能这就一条数据，代表它打算如何访问这一个表。 explain select * from t1 这里直接会扫描表的聚簇索引的叶节点，按顺序扫描过去拿到表里全部数据。 rows=32，说明这个表里就32条数据，全表扫描会全扫出来 filtered=100%，无where过滤...

1 回表的性能消耗 无论单列索引 or 联合索引，一个索引就对应一个独立的B+索引树，索引树节点仅包含： 索引里的字段值 主键值 即使根据索引树按条件找到所需数据，也仅是索引里的几个字段的值和主键值，万一你搞个select *，那就还得其他字段，就需回表，根据主键到聚簇索引里找，聚簇索引的叶节点是数据页，找到数据页才能把一行数据所有字段值读出来。 所以类似 select * from table order by xx1,xx2,xx3 得从联合索引的索引树里按序取出所有数据，接着对每条数据都走一个主键的聚簇索引查找，性能不高。 有时MySQL执行引擎可能认为，你要是类似 select ...

平时执行的更新语句，都是从磁盘上加载数据页到DB内存的缓存页，接着就直接更新内存里的缓存页，同时还更新对应的redo log写入一个buffer中。  既然更新了BP里的缓存页，缓存页就会变成脏页，就得有时机把那脏页给刷到磁盘文件，脏页刷盘机制，是维护了一个LRU链表。 后续若要加载磁盘文件的数据页到BP，但此时并无空闲缓存页，就得将部分脏缓存页刷入到磁盘，此时就会根据LRU刷盘。 万一你执行查询，需查大量数据到缓存页，可能导致内存里大量脏页需淘汰刷盘，才能腾出足够内存执行这条查询SQL。这时可能发现突然莫名线上DB执行某查询SQL就突然性能出现抖动，平时只要几十ms查询，这次一下子要...

水友们大清早都是积极交流技术，你确定不要一起来嘛~

多个事务同时并发更新一行数据时， 就有脏写问题。脏写绝对不允许，可依靠锁机制让多个事务更新一行数据的时候串行化，避免同时更新一行数据。 有个事务要来更新一行数据，他会先看这行数据有没有人加锁？看到没人加锁，该事务就会创建一个锁，包含自己的trx_id和等待状态，然后把锁跟这行数据关联在一起。 更新一行数据，必须将其所在数据页从磁盘文件读到缓存页才能更新，所以此时这行数据和关联的锁的数据结构，都在内存。 因为事务A给那行数据加了锁，所以此时该数据被加锁。就不能再让别人访问了！ 此时事务B也想更新那行数据，就检查当前这行数据是否被别人加锁，然后发现事务A抢先给这行数据加锁了，这可咋办？ 事务B想...

1 访问Buffer Pool时需要加锁吗？ 对MySQL执行CRUD的第一步，就是利用BP里的缓存来更新或查询。 假设MySQL同时接收到了多个请求，他自然会用多线程处理，那这多线程就可能会同时访问BP，即同时操作里面的缓存页，同时操作一个free链表、flush链表、lru链表。现在多线程来并发的访问这个BP，此时他们都是在访问内存里的一些共享数据结构，如缓存页、各种链表，必要加锁，然后让一个线程先完成一系列操作，比如说加载数据页到缓存页，更新free、lru链表，然后释放锁，接着下个线程再执行操作。 2 多线程并发访问加锁，DB性能还能好？ 即使就一个BP，多个线程会加锁串行执行，性能也...

Buffer Pool是啥？ 数据库中的数据，实际上最终都要存放在磁盘文件。 但对DB执行CRUD时，不可能直接更新磁盘数据，因为若你对磁盘进行随机读写操作，那速度太慢，随便一个大磁盘文件的随机读写操作，可能都要几百ms。真这么玩，你的DB每秒也就只能处理几百个请求了！ 在对数据库执行CRUD时，实际上主要都是操作内存里的Buffer Pool中的数据，即你实际上主要是对DB的内存里的数据结构进行增删改。 在DB内存里执行一堆增删改操作后，内存数据是更新了，但这时若DB突然宕机，那内存里更新好的数据不就都没了？ 所以MySQL也怕这个问题，于是引入了redo log，你在对内存数据进行增删改...

某天报警：某台机器部署的一个服务突然无法访问。谨记第一反应登录机器查看日志，因为服务挂掉，很可能因OOM。这个时候在机器的日志中发现了如下的一些信息： nio handle failed java.lang.OutOfMemoryError: Direct buffer memory at org.eclipse.jetty.io.nio.xxxx at org.eclipse.jetty.io.nio.xxxx at org.eclipse.jetty.io.nio.xxxx表明确实为OOM，问题是哪个区导致的呢？可以看到是：Direct buffer memory，还看到一大堆jetty...

假设知道自己的系统OOM了，咋办？ 解决OOM的初步思路 OOM必然说明系统中某区的对象太多，塞满那个区，而且一定无法回收掉那些对象，最终才导致内存溢出。 就得知道到底是什么对象太多了最终导致OOM，就必须得有一份JVM发生OOM时的dump内存快照。 OOM的时候自动dump 假设JVM发生OOM了，你觉得JVM是完全来不及处理然后突然进程就没了吗？也就是JVM是看起来非常突然的自己无法控制的就挂掉了吗？ 不是的，JVM本身在发生OOM之前都会尽可能的去进行GC腾出来一些内存空间，如果GC后还是没有空间，放不下对象， 才会触发内存溢出。 所以JVM自己对OOM情况的发生是完全有把控权的，他知...

1 个人简介 一位不致命的 Java Coder。双一流双非本科，迄今在百度、携程、华为等各厂都打了刻上我的名字的螺丝。一直专注于Java生态各种中间件原理、框架源码、微服务架构设计及实战，哦对了还有大数据算法！也获得过一些技术社区荣誉：阿里云开发者社区专家博主、腾讯云+社区2019、2020年度最佳作者、慕课网认证作者、CSDN百万阅读十万粉博客专家，简书优秀创作者兼《程序员》专题管理员。但最关键的还是在牛客网著有《Java源码面试解析指南》，阅读过万。 2 春招建议 结合我多年面试求职经历，也有了各种神奇的面试体验。 比如有的公司真的在乎地域，你家乡哪的呀，离公司近不近，有没有对象或者...

大部分工程师开发完一个系统后，部署生产环境的时候往往不对JVM进行参数设置，直接用默认JVM参数，这绝对是系统负载逐渐增高的时最大问题 如你不设置-Xmx、-Xms之类的堆内存大小，你启动一个系统，可能默认就给你几百MB的堆内存大小，新生代和老年代可能都是几百M。 很多后台系统都用默认JVM参数部署启动，前期没啥问题，但中后期开始，当有一定用户量和一定负载，就会出现惊喜。 Eden过小，导致频繁触发YGC，Survivor过小，导致经常在YGC后存活对象其实也没多少，但Survivor放不下，导致对象经常进入老年代，导致老年代过段时间就满，然后触发Full GC。 所以当时这个垂直电商APP的...

JVM参数示范(基于JDK 1.8) 用如下JVM参数运行代码： # 初始新生代大小 5M -XX:NewSize=5242880 # 最大新生代大小 5M -XX:MaxNewSize=5242880 # 初始堆大小 10M -XX:InitialHeapSize=10485760 # 最大堆大小 10M -XX:MaxHeapSize=10485760 -XX:SurvivorRatio=8 # 大对象阈值是10MB -XX:PretenureSizeThreshold=10485760 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC 如何打印JVM G...

更多精彩在公众号：JavaEdge 0 前言 线程就是为了能自动分配CPU时间片而生。异步模式设计可显著减少线程等待，在高吞吐量场景中，极大提升系统整体性能，降低时延。因此，像MQ这种需要超高吞吐量和超低时延中间件系统，其核心流程大量采用异步。 异步的本质是为了不占用过多的线程对象。比如一个响应时间是1秒的http1.1请求，并且不考虑http pipeline： 同步模式下，一个请求在未返回前，需要独占一个线程和一个httpconnection 异步模式下，一个请求在未返回前，只需要独占一个httpconnection,那个线程在提交完io任务后就回到线程池了 即QPS 5000时，同步...