概述在此前的日志中，我们介绍了 java1.8 版本以前的 hashmap 源码及工作原理：java HashMap 源码解析java8 对 

概述在我们的项目中，通常需要对各个方法实现 log 打印、上报监控数据、上报调用状态等等，这些通用的过程如果我们在每一个方法中都手动去添加是一个非常枯燥和容易出错的任务针对这样的场

概述redis 是目前最常用的开源缓存系统之一，它具有丰富的缓存数据结构、支持事务、院子操作等等特性，在实际的生产环境中有着非常丰富的用途java 有 jedis&nbs

事件还原项目在线上一直运行良好，CPU、内存都有较多剩余，CPU load 长期在 0.3 左右，接到通知周内公司业务促销，可能使 QPS 上升到日常值的三倍以上，认为完全可以承受，毫无压力活动当天午高峰业务无任何异常，到晚高峰时，突然一个接口返回时间大幅上升，从原来的 100 到 200 毫秒左右上升到 2 到 3 秒，其他接口均没问题 问题定位出现这个问题，首先是采用临时加机器的方法来解决，有所好转情况十分诡异，因为虽然接口返回时间达到了 2 到 3 秒，但返回数据是无误的接口做了什么呢？逻辑十分简单，调用了一个远程接口，然后组装成一个新的对象返回查看监控，我的接口调用的接口的 99.9% 的耗时在 450 毫秒左右，而我调用该远程接口的超时时间设置为 500 毫秒，如果超时，那么是无法返回任何数据的，而实际情况是数据返回无误，也就是说依赖的这个远程接口调用成功并在 500 毫秒以内返回了数据，而本地的创建并初始化对象占用了剩余的 1.5 到 2.5 秒的时间，这显然是不合

概述rabbitmq 是目前使用最为普及的消息队列组件，基于 AMQP 的 rabbitmq 在各方面设计都比较完善，同时，它具有非常丰富的功能与特性

概述此前的日志中，我们介绍了订单系统秒杀与抢购的设计原则、挑战及常用方案订单系统秒杀与抢购的设计本篇日志中，介绍一个现实可行且实际工作的秒杀流程详细设计，以及面临的各种问题与应对方案 流程图

概述java 线程状态通常包括以下几种：创建（new）就绪（runnable）运行（running）阻塞（blocked）time waitingwaiting消亡（dead）当需

概述在项目开发的过程中，遇到了一个奇怪的问题，使用原生的 com.rabbitmq.client 包操作 rabbitmq，失败率高达近 50%，超时非常严重经过仔细排查，发现是在创建 channel 的阶段耗时过长，那么，这究竟是为什么呢？经过阅读源码，我们看到 com.rabbitmq.client 的 Connection 在创建 Channel 的过程中通过 synchronized 关键字使用了锁，致使同一个 connection 上的所有线程同时只能有一个执行 channel 的创建过程，而其他线程需要阻塞等待这一过程的完成，这也就造成了超时的产生那么，如何解决这个问题呢？我们是否可以让所有的线程去共享和使用同一个 channel 呢？他们共享同一个 channel 也就不需要分别创建，因此就不会陷入对锁的争夺和等待了通过查阅官方文档，在com.rabbitmq.client Interface Channel中提到： While a Channel can be used by mu

概述高并发的抢购、秒杀功能是一个 web 系统面临的很大的一个挑战由于销售平台的促销活动，销售系统的 web 后台接口将承受平常几倍甚至几十倍的压力，这样，服务

概述众所周知，java 有两个最具革命性的版本，一个是 java1.5 一个是 java1.8，上一篇日志中，我们介绍了 java5 也就是