源码

通过分析源码可以更好理解List<T>的工作方式，帮助我们写出更稳定的代码。 List<T>源码地址: https://github.com/dotnet/corefx/blob/master/src/System.Collections/src/System/Collections/Generic/List.cs 。 接口 List<T>实现的接口：IList<T>, IList, IReadOnlyList<T> 其实.net framework经过多代发展， List 的接口确实是有点多了，添加新功能时为了兼容老功能，一些旧的接口又不能丢掉，所以看上去有点复杂。先 把这些接口捋一下： IEnumerator是枚举器接口，拥有枚举元素的功能，成员有Current, MoveNext, Reset，这三个函数可以使集合支持遍历。 IEnumerable是支持枚举接口，实现这接口表示支持遍历，成员就是上面的IEnumerator。 ICollection是集合接口，支持着集合的Count属性和CopyTo操作，另外还有同步的属性 IsSynchronized（判断是否线程安全）和SyncRoot（lock的对象） 。 IList是集合的操作接口，支持索引器，Add, Remove, Insert, Contains等操作。 泛型部分基本是上面这些接口的泛型实现，不过IList<T

代码数量 1.2.0版本代码量为1650行，去掉注释大概1500左右 代码模块 默认版本只包括核心模块，事件模块，ajax模块，form模块和ie模块，其它模块需要自行拓展加入，其中form模块只包含序列化操作和submit提交事件实现，ie模块只包括一点兼容性处理，两者码量极少，因此不做分析 执行结构 典型的即时函数，保证封装性 (function (global, factory) { // amd,cmd的模块化检测 })(this, function(window) { // zepto初始化代码 }) 模块结构 (function (global, factory) { // amd,cmd的模块化检测 })(this, function(window) { // 核心模块 var Zepto = (function () { }(); // 事件模块 ;(function (){ })(Zepto) // ajax模块 ;(function (){ })(Zepto) // form模块 ;(function (){ })(Zepto) // ie模块 ;(function (){ })() }) 架构原理 (function (global, factory) { // amd,cmd的模块化检测 })(this, function(window) { // 核心模块

自己通过学习ArrayList的源码，谈一下自己的感悟，不足之处，望多加指出，运维出身自学Java。 ArrayList源码中的属性 //默认容量 private static final int DEFAULT_CAPACITY = 10 ; //空数组，如果传入的容量为0时使用 private static final Object [ ] EMPTY_ELEMENTDATA = { } ; //空数组，传入容量时使用，添加第一个元素的时候会重新初始为默认容量大小 private static final Object [ ] DEFAULTCAPACITY_EMPTY_ELEMENTDATA = { } ; //存储元素的数组 transient Object [ ] elementData ; //集合中元素的个数 private int size ; add操作的源码 public boolean add ( E e ) { //检查是否需要扩容 ensureCapacityInternal ( size + 1 ) ; //把元素插到最后一位 elementData [ size ++ ] = e ; return true ; } private void ensureCapacityInternal ( int minCapacity ) {

FinalRequestProcessor是请求处理链中最后的一个处理器。 public class FinalRequestProcessor implements RequestProcessor { ZooKeeperServer zks; } FinalRequestProcessor只实现了RequestProcessor接口，需要实现process Request方法和shutdown方法。 核心属性为zks，表示Zookeeper服务器，可以通过zks访问到Zookeeper内存数据库。 我们看一下核心方法process Request代码： 同步代码块 synchronized (zks.outstandingChanges) { // Need to process local session requests // 当前节点，处理请求,若为事务性请求，则提交到ZooKeeper内存数据库中。 // 对于processTxn函数而言，其最终会调用DataTree的processTxn rc = zks.processTxn(request); // request.hdr is set for write requests, which are the only ones // that add to outstandingChanges. /

这片博文来源于我在公司部门内的分享，我隐去了和公司项目相关的部分，重新整理，从几个方面谈一下Nacos的设计（作为注册中心，基于此时的develop分支） 客户端与集群的交互 首先需要声明的是Nacos Cluster虽然内部使用了Raft协议但是对于Nacos客户端，Cluster实例是无状态的。客户端配置集群地址有两种方式： 1.通过配置serverAddr列表，客户端将访问集群时，随机从列表中选择一个实例访问： NamingService configService = NacosFactory.createNamingService("10.22.0.137:30253,10.22.0.137:30254,10.22.0.137:30255"); 当然，一般情况下我们并不会直接配置Nacos实例的IP，可用用域名，以便能动态发现。 2.通过Properties配置endpoint，定时访问，感知集群变化，并随机从接口返回的列表中选择一个实例访问，客户端会与Endpoint创建LONG PULL。 Properties properties = new Properties(); properties.put(PropertyKeyConst.ENDPOINT,"10.18.90.16"); properties.put(PropertyKeyConst.ENDPOINT

1. 描述 Container提供管理bean的能力。 基于Jetty-9.4.8.v20171121。 1.1 API public interface Container { // 增加一个bean，如果bean是一个Container.Listener则隐含调用addEventListener(Container.Listener)方法 // Container.Listener只关心两个事件：（1）增加bean（2）删除bean public boolean addBean(Object o); // 返回该Container里面所有的bean public Collection<Object> getBeans(); // 返回指定类型（包括子类）的bean public <T> Collection<T> getBeans(Class<T> clazz); // 返回指定类型（包括子类）的第一个bean，如果不存在则返回null public <T> T getBean(Class<T> clazz); // 删除指定的bean，如果bean是一个Container.Listener，隐含调用removeEventListener(Container.Listener) public boolean removeBean(Object o); //

我们手写一个Promise/A+规范,然后安装测试脚本，以求通过这个规范。 //Promise/A+源代码 // new Promise时，需要传递一个executor执行器，执行器立即执行 // executor接受两个参数，分别是resolve和reject // promise只能从pending到rejected,或者从pending到fulfilled // promise的状态一旦确认，就不会再改变 // promise有then方法，then接受两个参数，分别是promise成功的回调onFulfilled // 和promise失败的回调 onRejected // 如果调用then时，promise已经成功，则执行onFulfilled,并将promise值作为参数传递进去 // 如果promise已经失败，那么执行onRejected并把promise失败的原因作为参数传递进去 // 如果promise状态是pending,需要将onFulfilled和onRejected函数存放起来，等待状态确定后，再一次将对应的函数执行（发布） // then的参数onFulfilled和onRejected可以缺省 // promise可以then多次，promise的then方法返回一个promise // 如果then返回的是一个结果，那么就把这个结果作为参数

SpringMVC源码分析系列 说到java的mvc框架，struts2和springmvc想必大家都知道，struts2的设计基本上完全脱离了Servlet容器，而springmvc是依托着Servlet容器元素来设计的，同时springmvc基于Spring框架，Spring框架想必搞java的同学都很熟悉。 一进Spring的 官网 就发现了这样一排醒目的文字， spring可以让我们构造简单的、便携的、又快又易于扩展的基于jvm的系统和应用程序。 没错，基于Spring的MVC框架SpringMVC同样也可以构造具有这些特性的系统。 楼主从5.1开始写的第一篇《SpringMVC入门》开始，到现在差不多将近2个月的时间，之后陆陆续续写了几篇关于SpringMVC的源码分析文章。 有同学想研究SpringMVC源码或想深入学习一下SpringMVC的话，可以参考本系列文章。 废话不多说，本系列的文章都是基于Spring4.0.2版本的，楼主写的时候出到了4.0.2，也是最新的，现在的最新版本是4.0.5。 文章阅读顺序： 　　1. SpringMVC入门 　　　　SpringMVC的入门文章， 对于某些没接触过SpringMVC的同学来说，可以阅读以下，了解这个框架的结构以及使用，以入门的同学可以选择不看~ 　　2.

一、HashMap概述 在JDK1.8之前，HashMap采用数组+链表实现，即使用链表处理冲突，同一hash值的节点都存储在一个链表里。但是当位于一个桶中的元素较多，即hash值相等的元素较多时，通过key值依次查找的效率较低。而JDK1.8中，HashMap采用数组+链表+红黑树实现，当链表长度超过阈值（8）时，将链表转换为红黑树，这样大大减少了查找时间。 下图中代表jdk1.8之前的hashmap结构，左边部分即代表哈希表，也称为哈希数组，数组的每个元素都是一个单链表的头节点，链表是用来解决冲突的，如果不同的key映射到了数组的同一位置处，就将其放入单链表中。 jdk1.8之前hashmap结构图 jdk1.8之前的hashmap都采用上图的结构，都是基于一个数组和多个单链表，hash值冲突的时候，就将对应节点以链表的形式存储。如果在一个链表中查找其中一个节点时，将会花费O（n）的查找时间，会有很大的性能损失。到了jdk1.8，当同一个hash值的节点数不小于8时，不再采用单链表形式存储，而是采用红黑树，如下图所示。 jdk1.8 hashmap结构图 说明：上图很形象的展示了HashMap的数据结构（数组+链表+红黑树），桶中的结构可能是链表，也可能是红黑树，红黑树的引入是为了提高效率。 二、涉及到的数据结构：处理hash冲突的链表和红黑树以及位桶 1、链表的实现

最近在项目中，使用springmvc 进行上传文件时，出现了一个问题： org.springframework.web.multipart.MultipartException: The current request is not a multipart request 以上堆栈信息省略。 乍看一下，没啥值得讨论的地方，就是说当前这个请求不是一个multipart request，也就是说不是上传文件的请求。但是，这结果还是令我稍感意外，为什么呢？因为，我本意是将文件这个参数作为非必要参数，类似下面这样： @RequestMapping(value = "/upload", method = RequestMethod.POST) public ResultView upload(@RequestParam(value = "file", required = false) MultipartFile file) spring抛出上面的异常，就违背了我的本意，我明明设置了 “required = false”， 为什么还是不行？ 于是，带着疑问去看了一下spring的源码，下面就跟大家分享一下spring mvc对于文件上传的处理。 --------------------------------------------------我是华丽的分割线----------------