在前面的博文<小学徒成长系列—String关键源码解析>和<小学徒进阶系列—JVM对String的处理>中,我们讲到了关于String的常用方法以及JVM对字符串常量String的处理. 但是在Java中,关于字符串操作的类还有两个,它们分别是StringBuilder和StringBuffer.我们先来就讲解一下String类和StringBuilder.StringBuffer的联系吧. String.StringBuilder.StringBuffer的异同点 结合之前写的博…

老生常谈系列之Aop--Spring Aop源码解析(一) 前言 上一篇文章老生常谈系列之Aop--Spring Aop原理浅析大概阐述了动态代理的相关知识,并且最后的图给了一个Spring Aop实现的逻辑猜测,这是一种很普通的情形,如下图: 那下面,我们就通过源码分析来看Spring到底是怎么操作的,Spring是如何识别切面并且生成动态代理的. 在讲解Spring Aop实现之前,插两句Spring IOC的实现,因为Aop是依赖了IOC的实现的.可以参考Spring官网的原文如下: On…

DotNetOpenAuth 是 .Net 环境下OAuth 开源实现框架.基于此,可以方便的实现 OAuth 验证(Authorization)服务.资源(Resource)服务.针对 DotNetOpenAuth,近期打算整理出三篇随笔: DotNetOpenAuth Part 1 : OAuth2 Authorization 验证服务实现及关键源码解析 DotNetOpenAuth Part 2 : OAuth2 Resource 资源服务实现及关键源码解析 DotNetOpenAuth …

老生常谈系列之Aop--Spring Aop源码解析(二) 前言 上一篇文章老生常谈系列之Aop--Spring Aop源码解析(一)已经介绍完Spring Aop获取advice切面增强方法的逻辑,那这篇会介绍Spring Aop是怎么根据上面获取的advice生产动态代理的,并且会介绍advice是怎么执行的,例如怎么确保@Before的逻辑在@After前面执行. 源码分析 以下代码分析基于Spring版本5.2.x,另外部分地方我摘抄保留了英文注释,希望看官可以用心体会. 我们回到Abs…

本文系作者原创,转载请注明出处:http://www.cnblogs.com/further-further-further/p/7681826.html 在源码解析前,需要先理清线程池控制的运行状态,以及运行状态之间的任务调度 线程池控制状态(ctl ,原子操作 ,来自包java.util.concurrent.atomic ,保证线程并发安全),分为两大类:workerCount(当前运行的线程数)    runState(当前线程的运行状态) 1.runState运行状态: a>  RUN…

Stack简介 Stack是栈.它的特性是:先进后出(FILO, First In Last Out). java工具包中的Stack是继承于Vector(矢量队列)的,由于Vector是通过数组实现的,这就意味着,Stack也是通过数组实现的,而非链表.当然,我们也可以将LinkedList当作栈来使用!在“Java 集合系列06之 Vector详细介绍(源码解析)和使用示例”中,已经详细介绍过Vector的数据结构,这里就不再对Stack的数据结构进行说明了. Stack的继承关系 java…

学习思路 议程:代码结构-主干流程-分层架构-业务模型-数据库模型-消息模型 分布式架构:Api:横向扩展    rpc:纵向扩展 分层架构:Controller接口层.View/Manager逻辑层.DAO/Model数据库层 Nova与其他组件交互 业务模型——数据库建模 消息模型 rabbitmqctl list_queues,可以列出所有的消息队列 或者通过web管理界面,使用guest/openstack登录可以浏览   Nova代码结构 提纲挈领式的掌握,知道怎么定制化,知道组件之间…

本系列文章主要面向 TiKV 社区开发者,重点介绍 TiKV 的系统架构,源码结构,流程解析.目的是使得开发者阅读之后,能对 TiKV 项目有一个初步了解,更好的参与进入 TiKV 的开发中.本文是本系列文章的第六章节.重点介绍 TiKV 中 Raft 的优化. 在分布式领域,为了保证数据的一致性,通常都会使用 Paxos 或者 Raft 来实现.但 Paxos 以其复杂难懂著称,相反 Raft 则是非常简单易懂,所以现在很多新兴的数据库都采用 Raft 作为其底层一致性算法,包括我们的 TiK…

本文是系列文章<Maven 源码解析:依赖调解是如何实现的?>第三篇,主要介绍依赖调解的第一条原则:传递依赖,路径最近者优先.本篇内容较多,也是开始源码分析的第一篇,请务必仔细阅读,否则后面的文章可能就看不懂了.系列文章总目录参见:https://www.cnblogs.com/xiaoxi666/p/15583241.html. 场景 A有这样的依赖关系:A->B->C->X(1.0).A->D->X(2.0),X是A的传递性依赖,但是两条依赖路径上有两个版本的…

本文是系列文章<Maven 源码解析:依赖调解是如何实现的?>第四篇,主要介绍依赖调解的第二条原则:传递依赖,第一声明者优先.请按顺序阅读其他系列文章,系列文章总目录参见:https://www.cnblogs.com/xiaoxi666/p/15583241.html. 场景 路径最近者优先原则不能解决所有问题,比如这样的依赖关系:A-> C->X(1.0).A->D->X(2.0),X(1.0)和 X(2.0)的依赖路径长度是一样的,都为 2.那么到底谁会被解析使用…