记一次并发场景下的问题排查 上周周四，项目上线，我负责的部分主要是账单重构，说来也巧，本来是没有这个需求的，由于当时划分给我的项目其实已经被别的线接走了，后来经过讨论，这次的业务需要其他线支持，一下任务少了一大截，比较轻松，看了看下单流程，代码不符合我的审美就给重构了（现在想想真是自信过头，没经过架构评审，模型纯自己写的，就给重构了。。果不其然。。）。废话不说，直接进入正题。 问题出现四点钟上线完成，盯着日志，发现一单下单异常，仔细看了一下发现入参少了一个参数，问题很神奇，没有这个参数的情况下按理来说就不应该走到相应的流程去，但是却走进去了，这时候还没当回事，毕竟上线过程中，机器重启啥问题都可 ...

Java阻塞队列的原理分析 先看看BlockingQueue接口的文档说明： add：添加元素到队列里，添加成功返回true，由于容量满了添加失败会抛出IllegalStateException异常； offer：添加元素到队列里，添加成功返回true，添加失败返回false； put：添加元素到队列里，如果容量满了会阻塞直到容量不满； poll：删除队列头部元素，如果队列为空，返回null。否则返回元素； remove：基于对象找到对应的元素，并删除。删除成功返回true，否则返回false； take：删除队列头部元素，如果队列为空，一直阻塞到队列有元素并删除。 先看一个简单的Arra ...

Electrons使用指南前言Electrons是一个异步事件分发器，也是一个通道，结合了生产者消费者模型和SUB/PUB模式。传统的SUB/PUB模型，在publish事件的时候是直接同步执行所有的监听器，是同步阻塞的。现在结合RINGBUFFER的无锁的急速体验，设计了Electrons，意味电路，事件就相当于跑在电路中的电子，电子在电路中的传递速度非常之快，这也是这个插件的寓意。publish的事件会放到容器中等待消费者消费，消费者就是SUB方的listener，这里有个设计上的小缺陷，由于种种愿意，listener的注册是通过注解 + 接口的方式实现，后面会提到。下面进入主题 使用废话 ...

Go语言中的DispatcherGo使用goroutines来处理connection的读写事件，不会阻塞： 12345c, err := srv.newConn(rw) if err != nil { continue } go c.serve() c即为创建的connection，保存了该次请求的信息，然后再传递到对应的handler，handler就可以读取到请求的header信息，保证了请求之间独立。 Go中的ServeMux上面代码中提到了c（这个c就是connection）.serve（）方法。其实内部是调用了http包默认的路由器，通 ...

深入分析Object.wait和notify实现机制同一个obj对象调用wait、notify方法。 当线程A执行wait方法时，该线程被挂起。 当线程B执行notify方法时，唤醒一个被挂起的线程A。 lock对象、线程A和线程B三者是一种什么关系？根据上面的结论，可以想象一个场景： lock对象维护了一个等待队列list； 线程A中执行lock的wait方法，把线程A保存到list中； 线程B中执行lock的notify方法，从等待队列中取出线程A继续执行。 使用过程中有这么几个疑问： 进入wait/notify之前为什么要获取synchronized？ 线程A获取了synchr ...

Go语言中的Continuous Stack(连续栈)前言Go语言支持goroutine，每个goroutine需要能够运行，所以它们都有自己的栈。假如每个goroutine分配固定栈大小并且不能增长，太小则会导致溢出，太大又会浪费空间，无法存在许多的goroutine。为了解决这个问题，goroutine可以初始时只给栈分配很小的空间，然后随着使用过程中的需要自动地增长。这就是为什么Go可以开千千万万个goroutine而不会耗尽内存。Go1.3版本之后则使用的是continuous stack。 基本原理每次执行函数调用时Go的runtime都会进行检测，若当前栈的大小不够用，则会触发“中 ...

Go语言中的闭包 先看一个demo： 123456func f(i int) func() int { return func() int { i++ return i }} 函数f返回了一个函数，返回的这个函数就是一个闭包。这个函数中本身是没有定义变量i的，而是引用了它所在的环境（函数f）中的变量i。 我们再看一下效果： 1234c1 := f(0)c2 := f(0)c1() // reference to i, i = 0, return 1c2() // reference to another ...

Dubbo源码解析 — 服务的创建和暴露 前言本文主要就dubbo基础的XML解析开始，到服务的创建和发布，最终延展到底层netty的调用，给出一个初始化流程的解读。在这里你能看到dubbo一些优秀的抽象设计，以及底层源代码的解读。如有语义不明，联系紫苑。或者邮件ziyuan@2dfire.com。 service和server首先，当发布一个服务的Server时，我们需要编写一个Spring配置文件，形如以下： 123456<beans xmlns="..."> <dubbo:application name="hello-world-a ...

Dubbo源码解析 — 服务注册 前言对于分布式服务架构，解决服务的发现问题，引入了注册中心中间件，从而很好的解决了服务双方（消费方和提供方）的直接依赖问题。这种解耦的意义是非凡的，不仅在程序运行时保证了灵活性，在开发阶段也使得快速迭代成为了可能，甚至在运维层面也提供了非常好的自由度。 夸了这么多，但要实现一个完美的注册中心系统却不是一件那么容易的事儿，你必须时刻注意关注它的可用性（包括稳定，实时和高效），这一点在任何一款分布式系统中都是件很复杂的事儿。当然这篇文章并不是打算摆平这么个庞然大物，我们只是从dubbo和zookeeper之间的关系来了解一下在dubbo架构中注册中心的相关知识。 ...

Dubbo源码解析 — filter和listener 前言有一句说一句，这个标题的有点标题党的意思，我们在这里并不想给大家讲解filter和listener的概念、实现、功能等等。而是想给大家讲解filter和listener的注入过程，具体filter和listener请大家看一下官方文档，或者可以查看一下dubbo已知扩展点的实现。 问题我们看一下消费方执行流程： 1ReferenceBean --> ReferenceConfig --> RegistryProtocol --> DubboProtocol --> invoker --> exp ...