bit-ranger

大文件内容对比多线程版本

Thu, 28 May 2015 00:00:00 +0000

线程池
线程池消费拆分任务
线程池消费合并任务
测试

这是上一篇的续作，对于这个算法，其中可以同时进行的部分有

拆分后对每一个块的排序可以同时进行
合并时的不同范围之间可以同时进行，例如拆分为10个小块，那么1-5小块的合并跟6-10小块的合并过程可以同时进行
合并的不同阶段之间不可以同时进行，因为不同阶段之间有先后顺序
不存在对同一条数据的修改，所以无需进行并发控制

线程池

this.threadPoolExecutor = new ThreadPoolExecutor(8, 8, 10L, TimeUnit.SECONDS,
    new LinkedBlockingQueue<>(8),
    new CustomizableThreadFactory("fileSorterTPE-"),
    new ThreadPoolExecutor.CallerRunsPolicy());

线程池消费拆分任务

List<Future<Chunk>> splitFutureList = new ArrayList<>();
while (true){
    line = br.readLine();
    if(line != null){
        chunkRows.add(line);
    }
    if(line == null || chunkRows.size() >= initialChunkSize){
        if(chunkRows.size() > 0){
            final int rn = rowNum;
            final List<String> cr = chunkRows;
            rowNum += chunkRows.size();
            chunkRows = new ArrayList<>();
            Future<Chunk> chunk = threadPoolExecutor.submit(() -> {
                cr.sort(comparator);
                return initialChunk(rn, cr, file);
            });
            splitFutureList.add(chunk);
        }
    }
    if(line == null){
        break;
    }
}
chunkList = splitFutureList.stream().map(this::get).collect(Collectors.toList());

线程池消费合并任务

int currentLevel = INITIAL_CHUNK_LEVEL;
List<Future<Chunk>> mergeFutureList = new ArrayList<>();
while (true) {
    //从队列中获取一组chunk
    List<Chunk> pollChunks = pollChunks(chunkQueue, currentLevel);
    //未取到同级chunk, 表示此级别应合并完成
    if (CollectionUtils.isEmpty(pollChunks)) {
        mergeFutureList.stream().map(this::get).forEach(chunkQueue::add);
        mergeFutureList.clear();
        //chunkQueue 中只有一个元素，表示此次合并是最终合并
        if (chunkQueue.size() == 1) {
            break;
        } else {
            currentLevel++;
            continue;
        }
    }
    Future<Chunk> chunk = threadPoolExecutor.submit(() -> merge(pollChunks, original));
    mergeFutureList.add(chunk);
}

可以看到合并任务与拆分任务有些不同，拆分任务是在循环退出后才执行Future.get，因为拆分不用考虑先后；而合并任务在每次获取当前阶段的chunk结束时执行Future.get，这样才能避免不同的阶段之间产生混乱。

完整代码

测试

在上一篇中，使用单线程，1千万条数据排序耗时13秒；在同一台电脑上，使用多线程后，耗时6秒，时间减少了一半。

在拆分过程中，每个线程都要在内存中进行排序，在拆分和合并过程中，每个线程都要持有自己的读写缓冲区，这无疑会增大内存的使用量。

究竟消耗了多少内存，我们可以使用Java Mission Control来观察，jdk8的bin目录下jmc.exe即为此工具。

大文件内容对比

Thu, 26 Mar 2015 00:00:00 +0000

大文件内容排序
测试

最近接到一个需求，要对两个系统的订单进行对比，找出其中的差异，对比结果有4种：一致、不一致、丢失、多余。

如果数据量少，处理起来就很简单，例如要对A,B两份数据进行对比：

将数据A放入哈希表
遍历数据B，依据id从A中查找对应的订单
若从A中找到了对应的订单，则比较是否一致，并将此订单标记为已匹配
若从A中找不到对应的订单，则表示A丢失此订单
遍历A，筛选出所有未匹配的订单，这些订单都是A中多余的

但是如果数据量超大，在内存中处理就不合适了，数据需要放在磁盘上。基于哈希的对比算法，无法避免大量对磁盘的随机访问，因而无法使用buffer，完全的io读写性能太差，所以这个方案是不行的。

如果AB两个集合是有序的，那么对比将会变得容易，一次遍历就可以对比完成，例如以id排序

读取A指针对应的订单，读取B指针对应的订单
若两个订单id相等，则对比内容是否一致
若A指针订单id>B指针订单id，代表A中缺少B指针订单，记录结果，B指针移动到后一个
若A指针订单id<B指针订单id，代表A中多余了指针订单，记录结果，A指针移动到后一个

所以，这个问题可以拆分为：对A、B文件内容进行排序，双指针遍历 A、B。

大文件内容排序

对大文件的内容进行排序，可以使用拆分->排序->合并的思路

按行读取文件，将读到的行放入list
如果已读取的行达到了1万行，对list进行排序，将排序后的list逐行写入临时文件
打开多个临时文件，从每个文件的中逐行读取，选取其中订单id最小的行，写入新的临时文件
循环以上步骤，直至剩下一个文件

示例代码

 while (true){
     line = br.readLine();
     if(line != null){
         chunkRows.add(line);
     }
     if(line == null || chunkRows.size() >= initialChunkSize){
         if(chunkRows.size() > 0){
             chunkRows.sort(comparator);
             Chunk chunk = initialChunk(rowNum, chunkRows, file);
             chunkList.add(chunk);
             rowNum += chunkRows.size();
             chunkRows.clear();
         }
     }
     if(line == null){
         break;
     }
 }

 while (true){
     List<Chunk> pollChunks =  pollChunks(chunkQueue, currentLevel);
     if(CollectionUtils.isEmpty(pollChunks)){
         currentLevel++;
         continue;
     }
     //合并
     Chunk mergedChunk = merge(pollChunks, original);
     //chunkQueue 中没有后续的元素，表示此次合并是最终合并
     if(chunkQueue.size() == 0){
         chunkQueue.add(mergedChunk);
         break;
     } else {
         chunkQueue.add(mergedChunk);
     }
 }

完整代码

测试

在最后的多路合并中要考虑使用多少路进行合并，更少的路数，将产生更多的临时文件

拆分时需要考虑每个块的大小，过大的块将造成频繁的FULL GC

IO的缓冲容量区也要考虑，这将影响IO读写的速度，以及FULL GC的频率

以如下配置为例，在我的个人电脑上， cpu频率3.40GHZ，磁盘顺序读450MB/s，随机读190MB/s，顺序写250MB/s，数据宽度20为20字符对1千万条数据进行排序，耗时13秒。

FileSorter sorter = new FileSorter((p,n) -> p.compareTo(n),
    8, 50000, 1024*1024*2, new File("/var/tmp/fileSorter"), false);
long start = System.currentTimeMillis();
sorter.sort(file, dest);
long end = System.currentTimeMillis();
System.out.println(end - start);

该排序算法既有CPU计算又有IO，CPU计算时IO空闲，IO时CPU空间，如果把该方法改写成多线程版本，理论上可以提升不少速度。

大对象引起的频繁FULL GC

Sun, 15 Mar 2015 00:00:00 +0000

最近发现了频繁FULL GC的情况，查看GC日志后，发现每次FULL GC后，老年代都能回收大半以上的空间，这意味着有很多临时对象被分配到了老年代。

用jmap命令导出堆转储文件，然后用jvisualvm导入后进行分析，发现char[]占据了最多了内存。

其中有大量的对象达到了3M，被直接担保分配进了老年代，因为暂时不知道这些对象是怎么产生的，最快的解决办法就是增大担保分配的阈值。

下面就是测试过程

/**
 -server
 -XX:+UseConcMarkSweepGC
 -Xms20M
 -Xmx20M
 -Xmn10M
 -XX:SurvivorRatio=8
 -XX:PretenureSizeThreshold=2000000
 -XX:+PrintGC
 -XX:+PrintGCDetails
 -XX:+PrintGCDateStamps
 -XX:+PrintHeapAtGC
 -Xloggc:/var/logs/PretenureSizeThreshold.log
 -XX:+HeapDumpOnOutOfMemoryError
 -XX:HeapDumpPath=/var/dumps/PretenureSizeThreshold.hprof
 */
public class PretenureSizeThreshold {

    private static final int _1MB = 1000 * 1000;

    public static void main(String[] args) throws Exception{
        RuntimeMXBean mxBean =  ManagementFactory.getRuntimeMXBean();
        System.out.println(mxBean.getName());
        String pid = mxBean.getName().split("@")[0];

        byte[] allocation = new byte[3*_1MB];

        while (true){
            Thread.sleep(1000);
        }

    }
}

D:\Doc\MyRepo\learning-java>jmap -heap 14000
Attaching to process ID 14000, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.121-b13

using parallel threads in the new generation.
using thread-local object allocation.
Concurrent Mark-Sweep GC

Heap Configuration:
   MinHeapFreeRatio         = 40
   MaxHeapFreeRatio         = 70
   MaxHeapSize              = 20971520 (20.0MB)
   NewSize                  = 10485760 (10.0MB)
   MaxNewSize               = 10485760 (10.0MB)
   OldSize                  = 10485760 (10.0MB)
   NewRatio                 = 2
   SurvivorRatio            = 8
   MetaspaceSize            = 21807104 (20.796875MB)
   CompressedClassSpaceSize = 1073741824 (1024.0MB)
   MaxMetaspaceSize         = 17592186044415 MB
   G1HeapRegionSize         = 0 (0.0MB)

Heap Usage:
New Generation (Eden + 1 Survivor Space):
   capacity = 9437184 (9.0MB)
   used     = 2748888 (2.6215438842773438MB)
   free     = 6688296 (6.378456115722656MB)
   29.128265380859375% used
Eden Space:
   capacity = 8388608 (8.0MB)
   used     = 2748888 (2.6215438842773438MB)
   free     = 5639720 (5.378456115722656MB)
   32.7692985534668% used
From Space:
   capacity = 1048576 (1.0MB)
   used     = 0 (0.0MB)
   free     = 1048576 (1.0MB)
   0.0% used
To Space:
   capacity = 1048576 (1.0MB)
   used     = 0 (0.0MB)
   free     = 1048576 (1.0MB)
   0.0% used
concurrent mark-sweep generation:
   capacity = 10485760 (10.0MB)
   used     = 3000016 (2.8610382080078125MB)
   free     = 7485744 (7.1389617919921875MB)
   28.610382080078125% used

1815 interned Strings occupying 162040 bytes.

老年代占用的空间为3000016，这表示数组通过担保分配进入了老年代，多出来的16是对象头的体积

修改启动参数-XX:PretenureSizeThreshold=4000000

D:\Doc\MyRepo\learning-java>jmap -heap 2356
Attaching to process ID 2356, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.121-b13

using parallel threads in the new generation.
using thread-local object allocation.
Concurrent Mark-Sweep GC

Heap Configuration:
   MinHeapFreeRatio         = 40
   MaxHeapFreeRatio         = 70
   MaxHeapSize              = 20971520 (20.0MB)
   NewSize                  = 10485760 (10.0MB)
   MaxNewSize               = 10485760 (10.0MB)
   OldSize                  = 10485760 (10.0MB)
   NewRatio                 = 2
   SurvivorRatio            = 8
   MetaspaceSize            = 21807104 (20.796875MB)
   CompressedClassSpaceSize = 1073741824 (1024.0MB)
   MaxMetaspaceSize         = 17592186044415 MB
   G1HeapRegionSize         = 0 (0.0MB)

Heap Usage:
New Generation (Eden + 1 Survivor Space):
   capacity = 9437184 (9.0MB)
   used     = 5748624 (5.4823150634765625MB)
   free     = 3688560 (3.5176849365234375MB)
   60.91461181640625% used
Eden Space:
   capacity = 8388608 (8.0MB)
   used     = 5748624 (5.4823150634765625MB)
   free     = 2639984 (2.5176849365234375MB)
   68.52893829345703% used
From Space:
   capacity = 1048576 (1.0MB)
   used     = 0 (0.0MB)
   free     = 1048576 (1.0MB)
   0.0% used
To Space:
   capacity = 1048576 (1.0MB)
   used     = 0 (0.0MB)
   free     = 1048576 (1.0MB)
   0.0% used
concurrent mark-sweep generation:
   capacity = 10485760 (10.0MB)
   used     = 0 (0.0MB)
   free     = 10485760 (10.0MB)
   0.0% used

1815 interned Strings occupying 162040 bytes.

此时，老年代占用0，这表示数组没有达到大对象的标准，直接分配在了新生代

spring security 探秘

Thu, 12 Mar 2015 00:00:00 +0000

概述

Spring Security这是一种基于Spring AOP和Servlet过滤器的安全框架。它提供全面的安全性解决方案，同时在Web请求级和方法调用级处理身份确认和授权。在Spring Framework基础上，Spring Security充分利用了依赖注入（DI，Dependency Injection）和面向切面技术。

概述
Filter
HTTP
FilterChain
FilterSecurityInterceptor
AuthenticationManager
AccessDecisionManager
SecurityMetadataSource

本文的宗旨并非描述如何从零开始搭建一个 “hello world” 级的demo，或者列举有哪些可配置项（这种类似于词典的文档，没有比参考书更合适的了），而是简单描述spring-security项目的整体结构，设计思想，以及某些重要配置做了什么。

本文所有内容基于spring-security-4.0.1.RELEASE ,你可以在Github中找到它，或者使用Maven获取，引入spring-security-config是为了通过命名空间简化配置。

<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-web</artifactId>
    <version>4.0.1.RELEASE</version>
</dependency>
<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-config</artifactId>
    <version>4.0.1.RELEASE</version>
</dependency>

Filter

spring-security的业务流程是独立于项目的，我们需要在web.xml中指定其入口，注意该过滤器必须在项目的过滤器之前。

<filter>
    <filter-name>springSecurityFilterChain</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
    <filter-name>springSecurityFilterChain</filter-name>
    <servlet-name>/*</servlet-name>
</filter-mapping>

值得一提的是，该过滤器的名字具有特殊意义，没有特别需求不建议修改，我们可以在该过滤的源码中看到，其过滤行为委托给了一个delegate对象，该delegate对象是一个从spring容器中获取的bean，依据的beanid就是filter-name。

@Override
protected void initFilterBean() throws ServletException {
	synchronized (this.delegateMonitor) {
		if (this.delegate == null) {

			if (this.targetBeanName == null) {
				this.targetBeanName = getFilterName();
			}

			WebApplicationContext wac = findWebApplicationContext();
			if (wac != null) {
				this.delegate = initDelegate(wac);
			}
		}
	}
}

HTTP

我们可以在security中声明多个http元素，每个http元素将产生一个FilterChain，这些FilterChain将按照声明顺序加入到FilterChainProxy中，而这个FilterChainProxy就是web.xml中定义的springSecurityFilterChain内部的delegate。

<security:http security="none" pattern="/favicon.ico" />
<security:http security="none" pattern="/resources/**" />
<security:http security="none" pattern="/user/login" />

在http元素也就是FilterChain中，以责任链的形式存在多个Filter，这些Filter真正执行过滤操作，http标签中的许多配置项，如 <security:http-basic/>、<security:logout/>等，其实就是创建指定的Filter，以下表格列举了这些Filter。

利用别名，我们可以将自定义的过滤器加入指定的位置，或者替换其中的某个过滤器。

<security:custom-filter ref="filterSecurityInterceptor" before="FILTER_SECURITY_INTERCEPTOR" />

整体来看，一个FilterChainProxy中可以包含有多个FilterChain，一个FilterChain中又可以包含有多个Filter，然而对于一个既定请求，只会使用其中一个FilterChain。

FilterChain

上图列举了一些Filter, 此处将说明这些Filter的作用, 在需要插入自定义Filter时, 这些说明可以作为参考。

SecurityContextPersistenceFilter 创建一个空的SecurityContext（如果session中没有SecurityContext实例），然后持久化到session中。在filter原路返回时，还需要保存这个SecurityContext实例到session中。
RequestCacheAwareFilter 用于用户登录成功后，重新恢复因为登录被打断的请求
AnonymousAuthenticationFilter 如果之前的过滤器都没有认证成功，则为当前的SecurityContext中添加一个经过匿名认证的token, 所有与认证相关的过滤器（如CasAuthenticationFilter）都应当放在AnonymousAuthenticationFilter之前。
SessionManagementFilter 1.session固化保护-通过session-fixation-protection配置 2.session并发控制-通过concurrency-control配置
ExceptionTranslationFilter 主要拦截两类安全异常：认证异常、访问拒绝异常。而且仅仅是捕获后面的过滤器产生的异常。所以在自定义拦截器时，需要注意在链中的顺序。
FilterSecurityInterceptor 通过决策管理器、认证管理器、安全元数据来判断用户是否能够访问资源。

FilterSecurityInterceptor

如果一个http请求能够匹配security定义的规则，那么该请求将进入security处理流程，大体上，security分为三个部分：

AuthenticationManager 处理认证请求
AccessDecisionManager 提供访问决策
SecurityMetadataSource 元数据

以下代码摘自AbstractSecurityInterceptor，这是FilterSecurityInterceptor的父类，也正是在此处区分了web请求拦截器与方法调用拦截器。(代码有所精简)

protected InterceptorStatusToken beforeInvocation(Object object) {

	if (!getSecureObjectClass().isAssignableFrom(object.getClass())) {
		throw new IllegalArgumentException();
	}

	Collection<ConfigAttribute> attributes =
	        this.obtainSecurityMetadataSource().getAttributes(object);

	if (attributes == null || attributes.isEmpty()) {
		if (rejectPublicInvocations) {
			throw new IllegalArgumentException();
		}
		publishEvent(new PublicInvocationEvent(object));
		return null; // no further work post-invocation
	}

	if (SecurityContextHolder.getContext().getAuthentication() == null) {
	    //...
	}

	Authentication authenticated = authenticateIfRequired();

	// Attempt authorization
	try {
		this.accessDecisionManager.decide(authenticated, object, attributes);
	}
	catch (AccessDeniedException accessDeniedException) {
		publishEvent(new AuthorizationFailureEvent(object, attributes,
		            authenticated,accessDeniedException));
		throw accessDeniedException;
	}
}


private Authentication authenticateIfRequired() {
    Authentication authentication = SecurityContextHolder.getContext()
            .getAuthentication();

    if (authentication.isAuthenticated() && !alwaysReauthenticate) {
        return authentication;
    }

    authentication = authenticationManager.authenticate(authentication);

    SecurityContextHolder.getContext().setAuthentication(authentication);

    return authentication;
}

在FilterSecurityInterceptor的处理流程中，首先会处理认证请求，获取用户信息，然后决策处理器根据用户信息与权限元数据进行决策，同样，这三个部分都是可以自定义的。

<!-- 自定义过滤器 -->
<bean id="filterSecurityInterceptor"
            class="org.springframework.security.web.access.intercept.FilterSecurityInterceptor">
    <property name="securityMetadataSource" ref="securityMetadataSource"/>
    <property name="authenticationManager" ref="authenticationManager"/>
    <property name="accessDecisionManager" ref="accessDecisionManager"/>
</bean>

AuthenticationManager

AuthenticationManager处理认证请求，然而它并不直接处理，而是将工作委托给了一个ProviderManager，ProviderManager又将工作委托给了一个AuthenticationProvider列表，只要任何一个AuthenticationProvider认证通过，则AuthenticationManager认证通过，我们可以配置一个或者多个AuthenticationProvider，还可以对密码进行加密。

<security:authentication-manager id="authenticationManager">
    <security:authentication-provider user-service-ref="userDetailsService" >
        <security:password-encoder base64="true" hash="md5">
            <security:salt-source user-property="username"/>
        </security:password-encoder>
    </security:authentication-provider>
</security:authentication-manager>

考虑到一种常见情形，用户输入用户名密码，然后与数据比对，验证用户信息，security提供了类来处理。

<bean id="userDetailsService"
            class="org.springframework.security.core.userdetails.jdbc.JdbcDaoImpl" >
     <property name="dataSource" ref="dataSource"/>
</bean>

JdbcDaoImpl使用内置的SQL查询数据，这些SQL以常量的形式出现在JdbcDaoImpl开头，同样可以注入修改。

AccessDecisionManager

AccessDecisionManager提供访问决策，它同样不会直接处理，而是仅仅抽象为一种投票规则，然后决策行为委托给所有投票人。

<!-- 决策管理器 -->
<bean id="accessDecisionManager"
            class="org.springframework.security.access.vote.AffirmativeBased" >
    <property name="allowIfAllAbstainDecisions" value="false"/>
    <constructor-arg index="0">
        <list>
           <!-- <bean class="org.springframework.security.web.access.expression.WebExpressionVoter"/>-->
            <bean class="org.springframework.security.access.vote.RoleVoter">
                <!-- 支持所有角色名称，无需前缀 -->
                <property name="rolePrefix" value=""/>
            </bean>
            <bean class="org.springframework.security.access.vote.AuthenticatedVoter"/>
        </list>
    </constructor-arg>
</bean>

security提供了三种投票规则：

AffirmativeBased 只要有一个voter同意就通过
ConsensusBased 只要投同意票的大于投反对票的就通过
UnanimousBased 需要一致同意才通过

以下为AffirmativeBased决策过程

public void decide(Authentication authentication, Object object,
		Collection<ConfigAttribute> configAttributes) throws AccessDeniedException {
	int deny = 0;

	for (AccessDecisionVoter voter : getDecisionVoters()) {
		int result = voter.vote(authentication, object, configAttributes);

		switch (result) {
		case AccessDecisionVoter.ACCESS_GRANTED:
			return;

		case AccessDecisionVoter.ACCESS_DENIED:
			deny++;

			break;

		default:
			break;
		}
	}

	if (deny > 0) {
		throw new AccessDeniedException(messages.getMessage(
				"AbstractAccessDecisionManager.accessDenied", "Access is denied"));
	}

	// To get this far, every AccessDecisionVoter abstained
	checkAllowIfAllAbstainDecisions();
}

SecurityMetadataSource

SecurityMetadataSource定义权限元数据（如资源与角色的关系），并提供了一个核心方法Collection<ConfigAttribute> getAttributes(Object object)来获取资源对应的角色列表，这种结构非常类似于Map。

security提供了DefaultFilterInvocationSecurityMetadataSource来进行角色读取操作，并将数据存储委托给一个LinkedHashMap对象。

<!-- 资源与角色关系元数据 -->
<bean id="securityMetadataSource"
            class="org.springframework.security.web.access.intercept.DefaultFilterInvocationSecurityMetadataSource">
    <constructor-arg index="0">
        <bean class="top.rainynight.site.core.RequestMapFactoryBean">
            <property name="dataSource" ref="dataSource"/>
        </bean>
    </constructor-arg>
</bean>

DefaultFilterInvocationSecurityMetadataSource获取角色方法

public Collection<ConfigAttribute> getAttributes(Object object) {
	final HttpServletRequest request = ((FilterInvocation) object).getRequest();
	for (Map.Entry<RequestMatcher, Collection<ConfigAttribute>> entry : requestMap
			.entrySet()) {
		if (entry.getKey().matches(request)) {
			return entry.getValue();
		}
	}
	return null;
}

scheme 解释器

Mon, 21 Jul 2014 00:00:00 +0000

前段时间针对 scheme 语言写了一个解释器，现在就 fork 一下当时想法，整理一下其中的脉络，做一个思维快照，以期下次用C语言来实现时可以顺利地进行。成品在此：scheme-bootstrap。

词法作用域
抽象语法树
语法
基本操作和值
语法糖
- let,let*,letrec
内部定义
惰性求值
尾调用优化
垃圾回收

词法作用域

一条语句，在不同的函数当中可能具备不同的含义，其中变量的值取决于具体的作用域，所以对一条语句进行解释时需要考虑当时的上下文。然而lisp是一种函数式的编程语言，函数可以被当成数据来进行传递，这会产生一个问题，如果函数体中存在自由变量，那么这个函数的行为将产生不可控的变化，问题重点不是变化，而是不可控，在语言的使用者不需要函数行为变化的时候，自由变量会从外部作用域取值，自动产生行为的变化。这种作用域叫做动态作用域（Dynamic scope ）。

像java，javascript之类的语言，都是在对象内部维护一个成员变量，函数中自由的局部变量根据这个成员变量的值来确定行为，虽然函数的行为都可变，但它是可控的。为了实现可控，我们需要让语言满足人的直觉，即作用域和手写的代码结构相同，即使一个函数会被传递，其内部变量的值也应当追溯到函数定义时的作用域中。这种作用域就叫做词法作用域（Lexical scope）。

显然，实现词法作用域比动态作用域复杂些。实现动态作用域时，函数传递只要传递函数文本，然后插入到调用语句中进行解释就行了；而词法作用域需要为每个被传递的函数绑定一个定义时的作用域，通常将被传递函数体与定义时的作用域打包成一个数据结构，这个结构叫做闭包。 javascript就是使用闭包传递函数的。

抽象语法树

语言被写下来之后只是一个文本，其内容是对某种数据结构的形式化描述，在对语言进行解释前，必须先对这个文本进行解析，让其描述的结构出现在内存中，这种结构叫做抽象语法树（AST）。这个过程比较乏味，无非是对字符串进行扫描，发现嵌套括号就将其作为树中的一个节点。为了跳过这个过程，我选择用scheme来写解释器，lisp 天生就适合进行这样的表处理。类似这样用自己来解释自己的行为叫做自举。

语法

解释器逐行解释语句，那么碰到不同的语法关键字时应当触发不同的解释行为。

自求值表达式

当碰到数字和字符串时，表示这是一个自求值表达式，即写下的文本就是值。

quote

(quote foo)

引号表达式的值是去掉引号后的内容，其中 'foo 等价于 (quote foo)。

begin

(begin s1 s2)

begin 表达式表示其内容是顺序的多条语句，某些表达式只能支持单一的语句，用begin包裹这些语句后，就能当做一条语句使用。

(if <predicate> <consequent> <alternative> )

对if的处理是非常容易的，解释器先对 predicate 求值，如果值为真则对 consequent 求值，否则对 alternative 求值。

lambda

(lambda (x y)
    (+ x y))

lambda 表达式表示一个函数，对其求值就是将函数体，形参列表，作用域打包。

define

(define var Foo)

define 表达式表示定义，处理方式是求出 Foo 的值然后与 var 绑定，放入到当前作用域中。这个过程中隐含了对函数的定义，因为 Foo 可能就是一个lambda。

set!

(set! var Foo)

set! 语句提供了修改变量值的能力，如果没有这个关键字，scheme 就是纯粹的函数式语言，其函数将不会产生任何副作用，函数的行为将不可变。其处理方式类似于define，区别是一个新增，一个修改。需要注意 define 并不能代替 set!, define 定义的变量只能在某个作用域内屏蔽外部的同名变量；而set!将会沿着作用域链一直向上寻找匹配的变量名，然后进行修改。

变量

foo

对变量求值的过程与 set! 类似，解释器将沿着作用域链一直向上寻找匹配的变量名，然后取出变量的值。

函数调用

(plus a b)
((lambda (x y)
    (+ x y)) a b)

函数调用看似有两种形式，其实本质是一种，对变量 plus 的求值和对 lambda 的求值都将得到一个闭包，所以函数求值的真实过程是，求参数的值，将参数传递给闭包，然后求闭包的值。对闭包求值的过程为，扩展作用域，将参数值与对应的形参名绑定并放入作用域，这个过程类似于define，然后返回闭包中的函数过程体，该过程体为一条或多条语句，每条语句都需要被进行解释，这便产生一个递归的解释过程。

基本操作和值

函数并不能从无到有定义出来，其过程总会使用一些其他的函数，例如加法，那么加法从何而来？事实上，这些非常基本的操作都是无法直接定义出来的，它们需要从解释器中直接映射的。为了实现方便，以下操作都直接从解释器中映射：

+ - * / (其实减乘除可以用加法来实现，但是没这个必要)，
eq?
car
cdr
cons

scheme中函数与数据的界限非常模糊，car cdr cons等看似基本的操作其实可以用函数来实现。

(define (cons x y)
  (define (dispatch tag)
    (cond [(= tag 0) x]
          [(= tag 1) y]))
  dispatch)

(define (car z)
  (z 0))

(define (cdr z)
  (z 1))

基本值

true
false

语法糖

语法糖并非增加什么新功能，而是让某些以有的功能写起来更舒服。对语法糖的处理也比较简单，就是将其结构变化成解释器能够认识的形式，然后发送给解释器重新解释。

define

(define (foo bar)
  <body>)

该表示法为函数定义的语法糖，用基本的define定义函数时，每次都要写出lambda，比较繁琐。该表示法等价于如下形式

(define foo (lambda (bar)
                <body>))

cond

(cond [<p1> <e1>]
      [<p2> <e2>]
      [else e   ])

cond 表达式类似于常见的switch结构，但是每个case自带break，所以无法进入多个case。cond 可以转换成嵌套的if，然后将转换后的表达式转发给解释函数重新解释。

(if p1
    e1
    (if p2
        e2
        e))

and

(and c1 c2)

短路的逻辑与可以用嵌套的if来实现

(if c1
    (if c2
        true)
    false)

(or c1 c2)

短路的逻辑或也可以用嵌套的if来实现

(if c1
    true
    (if c2
        true))

let,let*,letrec

这三个语法糖提供了三种不同的方式来定义作用域，这三种表示法的作用各不相同，它们都建立在lambda的基础上。

let

(let ([<var1> <exp1>]
      [<var2> <exp2>])
      <body>)

let 表达式提供了定义一个作用域并绑定互斥变量的功能，var1 与 var2 在语义上没有先后之分，也不能相互访问。 let 表达式等价于如下如下形式，这是一个普通的函数调用。

((lambda (<var1> <var2>)
    <body>)
<exp1>
<exp2>)

let*

(let* ([<var1> <exp1>]
       [<var2> <exp2>])
      <body>)

let* 表达式提供了定义一个作用域并先后绑定变量的功能，var1 与 var2 在语义上存在先后之分，var2 可以访问 var1，而 var1 不能访问 var2。 let* 表达式等价于如下形式

(let ([<var1> <exp1>])
     (let ([<var2> <exp2>])
                <body>))

letrec

(letrec ([<var1> <exp1>]
         [<var2> <exp2>])
        <body>)

letrec 表达式提供了定义一个作用域并同时绑定变量的功能，var1 与 var2 在语义上为同时定义，var2 可以访问 var1，且 var1 可以访问 var2， letrec 的存在意义在于屏蔽外部同名变量，假定当前作用域外部存在一个变量 var2,那么let和let* 中的var1求值时如果需要访问var2，那么将会访问这个外部的var2, 而letrec不同，如果letrec的var1求值是需要访问var2,那么这个var2的值同一作用域内的那个var2的值。 letrec 表达式等价于如下形式

(let ([<var1> **undefined**]
      [<var2> **undefined**])
      (set! var1 <exp1>)
      (set! var2 <exp2>
      <body>)

解释器在对变量求值时会检查变量的值，如果其值为一个未定义标记，则会提示未定义错误。

内部定义

函数的内部可以嵌套地使用define语句，但是define在写成文本时是存在先后的，但是函数内部定义的语义应当是同时定义，所以在对lambda进行解释时需要一些调整，调整内容如下，

扫描出lambda体内的所有define语句，只扫描内部定义的第一层无需嵌套，然后将define的变量名和值表达式(无需求值)装配成letrec的kv绑定形式；
扫描出lambda内部的所有非定义语句将这个序列作为letrec的body；
用上面得到的两个部分组成一个letrec；
用新得到的letrec作为body构造一个新的 lambda 来替换原来的lambda。

上文描述的含义为：

(lambda (foo)
        (define a <expa>)
        (define b <expb>)
        <body>)

等价于如下形式

(lambda (foo)
    (letrec ([a <expa>]
             [b <expb>])
        <body>))

惰性求值

为了实现惰性求值，需要提供一种延迟计算一个表达式的能力，实现方式有两种，一种是将解释器改造成惰性求值解释器，另一种是用一对关键字 delay force 提供局部的惰性和强制求值能力。

惰性求值解释器

对任何一个表达式求值时，都不直接求值表达式而是创建一个代理的数据结构来包裹表达式和求值时的环境，这个代理可以作为该表达式值的许诺进行传递。当需要使用表达式的值时，再对这个代理进求值，解释器并不会完整地求出整个表达式的值，其实这个值依旧是一个代理，解释器很懒，最多只工作到刚刚满足需求的程度。

理论上来讲，惰性求值的效率应当高过普通的求值器，但是它有个缺陷，惰性求值与赋值语句配合使用时经常会出现意料之外的情况，因此 haskell 这种惰性求值的语言同时也是纯函数式的语言。

因为赋值产生问题例子如下，其函数的返回值并不会发生任何变化，因为赋值表达式被惰性了，并没有真正执行。要解决这个问题，必须提供一个机制让语言使用者主动地强制执行该表达式。

(define (f x)
  (set! x 998)
  x)

delay/force

用这种方式提供惰性功能并没什么理论上的变化，只是让普通的解释器增加两个case, 在碰到delay时生成代理，碰到force时强制执行。其优点是简单易用，同时缺点也非常明显，必须为高阶函数提供两个版本，一个版本普通，一个版本惰性，而且在使用惰性功能时，代码中会遍布这两个关键字。

在我写的解释器中用delay/force的方式提供了惰性求值的功能。

尾调用优化

scheme语言没有循环，循环的本质就是在递归时不断对一个变量进行读写，这个变量作为终止条件便可以控制递归的次数，在没有循环时，可以用在递归函数中传递这个变化的因子来代替。这种递归比较特殊，它在栈中只占一帧，并不会在栈空间累积数据，要使递归能够代替循环，必须进行尾调用优化。

因为我的解释器是自举的，scheme语言本身提供了对尾调用的优化，在对递归的函数进行解释时，保存当前一帧中的重要数据的负担被转嫁到了解释器中，如果编写解释器的语言恰好也支持尾调用优化，这一负担会消弭于无形。但是如果编写解释器的语言没有尾调用优化呢？那我们就需要自己处理这种优化。

处理尾调用优化比较复杂，需要将解释器写成寄存器风格，用栈来保存寄存器中的历史值。在解释一个表达式前，将寄存器值入栈，解释一个表达式后，栈中内容弹出到寄存器中，解释一个表达式的值不会在栈中留下任何数据。如果表达式中存在子表达式，那么这个过程也适用于子表达式，显而易见，子表达式解释前的数据入栈时将压在父表达式的数据之上。如果子表示的嵌套层数太深，数据将有可能撑满整个栈，递归函数通常极有可能嵌套太深。

基于这种解释器模型，可以选择让表达式序列中的最后一条语句在解释之前数据不入栈，这最后一条语句执行完毕后，直接修改寄存器，数据也不必出栈。如果最后一条语句仅仅为一个函数调用，那么这个语句将不会在栈中累积数据，即使这个函数是递归的也同样如此。

垃圾回收

垃圾回收的目标是函数执行时扩展的作用域以及函数的闭包，判别一段内存是否可回收的方式是枚举根节点。从寄存器中的指针出发，经过一系列car,cdr能达到的对象，有可能影响未来的计算过程，那些不能达到的都是可回收的垃圾。

如果采用停止并复制的算法进行回收，其流程大致如下：

GC开始之前，将所有寄存器内容保存到一个预先分配好的表里，并让root寄存器指向这个表的顶部序对。
GC时，先从root表开始，一个一个地复制序对，原内存中被复制的序对，car标记为“破碎的心”，cdr放置一个前向指针，指向序对复制后的新位置。
状态控制，free，scan。 free 指向下一段可用内存，内存分配时递增的地址就是通过它来实现，通过他可以知道当前内存的使用状态。
GC循环，scan初始指向一个新内存区的对象A，而该对象car,cdr仍指向旧内存区的对象，假定scan正在扫描A对象的car，此时需要检查car指向的对象是否已被复制。如果未复制就将其复制到free所指的位置并更新free，同时在旧对象做标记，然后更新car使其指向复制后的对象。如果car指向的对象已被复制，则car更新为将该旧对象的cdr中的前向指针。当scan超过free时GC结束。

设计模式与原则

Sun, 22 Jun 2014 00:00:00 +0000

设计模式的定义：在某情境下，针对某问题的某种解决方案。但是满足此定义的方案并不一定是设计模式，设计模式要求解决方案必须是可复用的。设计模式的作用大体上是：优化结构，消除依赖，将面向过程转为面向对象。按照功能，一般可以将设计模式分为创建型，行为型，结构型三大类。本文将列举这些设计模式，并对每个设计模式进行简要描述，描述格式为：名称，定义，案例，适用性，结构，效果，应用，相关。

创建型
- 单例模式
- 工厂模式
行为型
结构型

设计模式是工程师们从工作中总结出来的经验之谈，这些经验除了设计模式，还有一些设计原则，严格来讲，这些东西都是教条，它告诉我们只要按照规矩来，就不容易犯错。当遇到一特殊情况时，打破原则也没什么大不了的。

这些原则包括：

单一责任原则：一个类应该只有一个引起变化的原因。

里氏替换原则：子类可以扩展父类的功能，但不能改变父类原有的功能。

依赖倒置原则：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

接口隔离原则：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。

最少知识原则：一个对象应该对其他对象保持最少的了解。

开闭原则：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

以及一些叫不上名的原则：

找出应用中可能需要变化之处，把他们独立出来，不要和那些不需要变化的代码混在一起。

针对接口编程，而不是针对实现编程。

多用组合少用继承。

创建型

单例模式

定义

确保一个类只有一个实例，并提供一个全局访问点。

案例

需要对系统的注册表进行操作，如果同时存在多个注册表对象的话，将无法对并发访问或者临界值进行控制。

建立一个注册表获取类，从其静态方法中获取注册表对象，单例采用双重检查法创建。

适用性

当对象的操作目标是当前环境中的唯一资源时

结构

效果

将可以进行并发访问控制

应用

Runtime

NumberFormat

相关

简单工厂

工厂模式

分类

工厂方法，抽象工厂，（简单工厂算工厂方法的特例）

定义

工厂方法：定义了一个创建对象的接口，但由子类决定需要实例化的类是哪一个。工厂方法将类的实例化推迟到子类。

抽象工厂：定义一个接口，用于创建相关或依赖对象的家族，而不用明确指定具体的类。

案例

现有系统需要获取一组批萨饼的调料，但是同样的调料在不同的地点会有不同，如海边的海鲜是新鲜的，而内地的海鲜是冷冻的，为了方便扩展，获取的调料不能依赖具体的地点。

解决方案：将获取调料的地点抽象，由运行时的具体地点生成一组调料。

适用性

当需要依赖运行时上下文来决定生成的产品家族时使用抽象工厂

区别

工厂方法：一个抽象产品，可以派生出多种具体产品；一个抽象工厂类，可以派生出多个具体工厂。

抽象工厂：多个抽象产品类，每个抽象产品类可以派生出多个具体产品类。一个抽象工厂类，可以派生出多个具体工厂类。每个具体工厂类可以创建多个具体产品类的实例。

结构

工厂方法

抽象工厂

效果

能轻松方便地构造对象实例，而不必关心构造对象实例的细节和依赖条件。

类数量暴增

应用

基本装箱类

Collection的iterator()

log4j

行为型

策略模式

定义

定义了算法家族，分别封装起来，让他们之间可以相互替换，此模式让算法的变化独立于使用算法的客户。

案例

存在一个模拟鸭子的程序，现在需要为其增加飞翔的功能，在鸭子的抽象类上增加fly()方法后，飞翔能力将传播到所有的子类中。但是，本不应该会飞的 “模型鸭” 也继承了飞翔能力，如果将飞翔能力抽象为 Flayable接口，那么随着程序的扩展，那么所有子类都必须重新实现fly()方法，如此一来将出现大量的重复代码，如果已经现存很多扩展类，修改这些类也是很大的工作量。

此时的解决方案是：将飞翔行为抽象，并提供几个通用实现，将鸭子的飞翔委托给飞翔行为，在抽象类中增加set方法注册委托，这样的改动不会影响现有的结构。

适用性

当类的某个行为随着扩展不断发生变化，而且这种变化只有有限的几种时。

结构

效果

积极：

1.类与行为可以分别扩展，而且扩展类可以自由设置行为，甚至在运行时改变。

2.类预置了多个算法，需要要判断调用时上下文从而选择不同算法。策略模式可以消除代码中的 if lese 将选择权交给客户

消极:

1.客户端必须知道所有的策略类，并自行决定使用哪一个策略类 2.策略模式将造成产生很多策略类，可以通过使用享元模式在一定程度上减少对象的数量。

应用

ThreadPoolExecutor中的RejectedExecutionHandler

SpringSecurity中的AccessDecisionManager

相关

模板方法模式

命令模式

状态模式

模板方法

定义

在一个方法中一定一个算法的骨架，而将某些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。

案例

现有一个冲泡饮料的算法，泡咖啡和泡茶的步骤基本相同，但是在加调料的这一步有所区别，如何在不需要重写整个冲泡过程的前提下扩展？

解决方案：将冲泡过程中的放调料步骤抽象出来做成hook，待具体的实现者来补全算法，而不必重写整个冲泡过程。

适用性

当算法的整体骨架可被复用，只有其中某个步骤可变时

结构

效果

复用算法骨架

算法可变步骤中的每一个特例都要为其创建一个新类

应用

Collections.sort

相关

与策略模式不同，策略模式定义一个算法家族，算法可以互换，而模板方法定义一个算法大纲，其中个别的步骤可以有不同实现。

状态模式

定义

允许对象内部状态改变时改变它的行为，对象看起来好像修改了它的类。

案例

需要模拟一个自动售货机程序，如果没有投币则只能投币；如果已投币则不能再投币，可以选择退币或者出货；选择出货后如果有货则出货并结束，如果断货则提示断货。

可以用大量的 if else 将如上描述写成过程话的判断语句以完成功能，然而现在需要增加一个功能，有十分之一的几率双倍出货。这样一来就需要在每个动作方法内判断当前操作者是不是幸运儿。

解决方案：将状态封装成独立的类，并将动作委托到代表当前状态的对象。省去了类中冗长的状态判断。

适用性

行为因为上下文的不同而需要随之变化

代码中包含大量与对象状态有关的条件语句:一个操作中含有庞大的多分支的条件（if else(或switch case)语句，且这些分支依赖于该对象的状态。

结构

效果

它将与特定状态相关的行为局部化，并且将不同状态的行为分割开来

它使得状态转换显式化

状态对象可被共享

状态模式的使用必然会增加系统类和对象的个数。

状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。

应用

java.util.Iterator

动作游戏连招

相关

是策略模式的增强版，区别在于意图，策略模式虽然也可以在运行时改变行为，但是策略模式通常有一个最适合的策略对象；而状态模式需要在多个状态对象中游走，没有所谓的最适合状态。

命令模式

定义

将请求封装成对象，以便使用不同请求，队列或日志来参数化其他对象，命令模式也支持可撤销的操作。

案例

通用遥控器，当目标为电视时，上下键可以是换台，调整音量；当目标为空调时，上下键可以是调温或者调整定时；而且可以方便地扩展以兼容不同电器。

解决方案，将遥控器与电器接偶，将遥控器每个按钮抽象为一个命令，由使用者提供命令，遥控器呼叫此命令，由命令自身呼叫真实目标。

适用性

当请求的真实目标不明确，或者对请求进行不明确的处理时(如队列，宏命令，日志记录等)。

结构

效果

积极的：

降低系统的耦合度:Command模式将调用操作的对象与知道如何实现该操作的对象解耦。

组合命令:你可将多个命令装配成一个组合命令，即可以比较容易地设计一个命令队列和宏命令。一般说来，组合命令是Composite模式的一个实例。

增加新的Command很容易，因为这无需改变已有的类。

可以方便地实现对请求的Undo和Redo。用栈存储操作序列，可以实现多层次撤销。

消极的：

导致某些系统有过多的具体命令类

应用

java.lang.Runnable

javax.swing.Action

游戏中的自定义键位

相关

策略模式聚焦的是对相同请求更换解决方案的灵活性；而命令模式聚焦的是对多请求变化的封装以及对相同请求不同的请求形式解决方法的可复用性

组合模式

观察者模式

定义

定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，所有所有依赖者都会接到通知并自动更新

案例

需要在展板上实时显示当前温度，温度数据来自温度计。初步方案1,是定时询问温度计然后更新数据，这样就需要再开一个定时器线程，如果以后会有更多的功能需要获取温度计数据，那么线程数量将失去控制。数步方案2是当温度计数据发生变化时，直接通知这些数据请求者，但是当有新的请求者时，需要打开温度计类增加一个请求者。

结局方案：将需要获取温度计数据的请求者抽象，然后注册到温度计中形成一个列表，每当温度计数据发生变化，就依次通知这些注册的对象。

适用性

当一个抽象模型有两个方面, 其中一个方面依赖于另一方面的状态。将这二者封装在独立的对象中以使它们可以各自独立地改变和复用。

当对一个对象的改变需要同时改变其它对象 , 而不知道具体有多少对象有待改变。

当一个对象必须通知其它对象，而它又不能假定其它对象是谁。换言之 , 你不希望这些对象是紧密耦合的。

结构

效果

Observer模式允许你独立的改变目标和观察者

观察者模式可以实现表示层和数据逻辑层的分离

支持广播通信

应用

java.util.EventListener

相关

终结者模式

单例模式

迭代器模式

定义

提供一种方法顺序访问聚合对象中的每个元素，而又不暴露其内部表示。

结构

效果

封装性良好，用户只需要得到迭代器就可以遍历，而对于遍历算法则不用去关心。

增加新的聚合类需要对应增加新的迭代器类，类的个数成对增加

应用

java.util.Iterator java.util.Enumeration

相关

组合模式，常用来便利组合模式的对象图

备忘录模式

工厂方法模式，迭代器对象由实现类提供

结构型

装饰者模式

定义

动态地将职责附加到对象上，若要扩展功能，装饰者提供了比继承更有弹性的替代方案。

案例

模拟一个冲泡咖啡的程序，调料种类未知，而且以后可能增减，每种调料价格不同，客户可自行选择调料份量，现在需要计算该咖啡的价格。初步方案是列出所有可能的组合，然后计算组合的价格，但是如果调料种类较多，那么组合将会爆炸，考虑到调料的份量有无限种可能，列举组合方式不可行。

解决方案：将咖啡抽象，将每种调料对应一种咖啡，如加奶的咖啡，加摩卡的咖啡等，这些调料的咖啡成分由客户自己提供。

适用性

当需要对一个对象以可选的方式增强功能时

当无法使用继承的方式增强功能时

结构

抽象组件角色(Component)：定义一个对象接口，以规范准备接受附加责任的对象，

即可以给这些对象动态地添加职责。

具体组件角色(ConcreteComponent) :被装饰者，定义一个将要被装饰增加功能的类。

可以给这个类的对象添加一些职责

抽象装饰器(Decorator):维持一个指向构件Component对象的实例，

并定义一个与抽象组件角色Component接口一致的接口

具体装饰器角色（ConcreteDecorator):向组件添加职责。

效果

运行时扩展现有对象，比继承灵活。

产生很多小类

应用

java.io.BufferedInputStream(InputStream)

java.io.DataInputStream(InputStream)

java.io.BufferedOutputStream(OutputStream)

java.util.zip.ZipOutputStream(OutputStream)

java.util.Collections# checkedList

Map

Set

SortedSet

SortedMap

相关

可与工厂模式和生成器模式配合使用

Decorator模式不同于Adapter模式，因为装饰仅改变对象的职责而不改变它的接口；而适配器将给对象一个全新的接口。

Strategy模式：用一个装饰你可以改变对象的外表；而Strategy模式使得你可以改变对象的内核。这是改变对象的两种途径。

适配器模式

定义

将一个类的接口，转换成客户期望的另一个接口，适配器让原本接口不兼容的类可以合作无间。

案例

插座有插头型号对不上，用适配器抓换下。

适用性

想使用一个已经存在的类，而它的接口不符合需求时。

结构

类适配器

对象适配器

应用

java.util.Arrays# asList()

java.io.InputStreamReader(InputStream)

java.io.OutputStreamWriter(OutputStream)

相关

类似装饰者，而者都是包装对象，但是装饰者从不转换接口，只是增加职责，而适配器正是转换接口。

外观模式

代理模式

定义

为另一个对象提供一个替身或占位符以控制对这个对象的访问

案例

需要编写一个类来监控远程服务器上的一些数据，但是希望这个类易于使用。结局方案，将远程服务上的数据抽象成一个接口，用RMI进行通信，看起来就好象直接操纵了远程对象。

适用性

1) 远程代理（Remote Proxy）为一个位于不同的地址空间的对象提供一个本地的代理对象。这个不同的地址空间可以是在同一台主机中，也可是在另一台主机中，远程代理又叫做大使(Ambassador)

2) 虚拟代理（Virtual Proxy）根据需要创建开销很大的对象。如果需要创建一个资源消耗较大的对象，先创建一个消耗相对较小的对象来表示，真实对象只在需要时才会被真正创建。

3) 保护代理（Protection Proxy）控制对原始对象的访问。保护代理用于对象应该有不同的访问权限的时候。

4) 智能指引（Smart Reference）取代了简单的指针，它在访问对象时执行一些附加操作。

5) Copy-on-Write代理：它是虚拟代理的一种，把复制（克隆）操作延迟到只有在客户端真正需要时才执行。一般来说，对象的深克隆是一个开销较大的操作，Copy-on-Write代理可以让这个操作延迟，只有对象被用到的时候才被克隆。

结构

效果

封装实现细节，只暴露数据抽象

延迟加载

权限控制

应用

java.lang.reflect.Proxy

RMI

相关

与装饰者很类似，然而目的不同，装饰者增加行为，代理模式控制访问

外观模式

定义

提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。

案例

程序由多个子系统联合起来工作，而且这些子组件需要使用者自己组装，这样使用起来会很复杂，而且客户与子组件耦合较高。

解决方案，提供一套简化的接口，客户端可以直接操作此接口，而无需理会复杂的系统结构。

适用性

当需要为一个复杂子系统提供一个简单接口时。

结构

效果

对客户屏蔽子系统组件，减少了客户处理的对象数目并使得子系统使用起来更加容易。

只是提供了一个访问子系统的统一入口，并不影响用户直接使用子系统类。

不能很好地限制客户使用子系统类

增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。

应用

java.lang.Class

相关

适配器模式

组合模式

定义

允许你将对象组合成树形结构来表现“整体/部分”层次结构。组合能让客户以一致的方式处理个别对象以及对象组合。

案例

菜单中有很多道菜，而且其中甜点是个子菜单，现在需要打印整个菜单。

解决方案是：将子菜单与总顶层菜单的接口统一起来，都为Menu类型，大Menu内部维护菜单列表以及子Menu。

适用性

想表示对象的部分-整体层次结构

希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。

需要注意的是，虽然通常情况下组合模式以树形结构体现，但其实不是一回事，组合模式拥有更抽象的语义，它是一种整体与部分一致的抽象。

结构

效果

定义了包含基本对象和组合对象的类层次结构基本对象可以被组合成更复杂的组合对象，而这个组合对象又可以被组合，这样不断的递归下去。

简化客户代码客户可以一致地使用组合结构和单个对象。

使得更容易增加新类型的组件

更难以排除特定类型的组件

应用

javax.swing.JComponent# add(Component)

java.awt.Container# add(Component)

java.util.Map# putAll(Map)

java.util.List# addAll(Collection)

java.util.Set# addAll(Collection)

相关

可与迭代器模式搭配使用

Java Concurrent

Sun, 18 May 2014 00:00:00 +0000

线程安全的类
Thread
- interrupt
- join
- 同步
- 锁
线程安全集合
线程池
Executor 框架
同步工具
Lock工具
原子变量
并发随机数
性能与可伸缩性

线程拥有通过程序运行的独立的并发路径，并且每个线程都有自己的程序计数器，称为堆栈和本地变量。线程存在于进程中，它们与同一进程内的其他线程共享内存、文件句柄以及进程状态。

JDK 5.0 中的并发改进可以分为三组：

JVM 级别更改。大多数现代处理器对并发对某一硬件级别提供支持，通常以 compare-and-swap （CAS）指令形式。CAS 是一种低级别的、细粒度的技术，它允许多个线程更新一个内存位置，同时能够检测其他线程的冲突并进行恢复。它是许多高性能并发算法的基础。在 JDK 5.0 之前，Java 语言中用于协调线程之间的访问的惟一原语是同步，同步是更重量级和粗粒度的。公开 CAS 可以开发高度可伸缩的并发 Java 类。这些更改主要由 JDK 库类使用，而不是由开发人员使用。
低级实用程序类 – 锁定和原子类。使用 CAS 作为并发原语，ReentrantLock 类提供与 synchronized 原语相同的锁定和内存语义，然而这样可以更好地控制锁定（如计时的锁定等待、锁定轮询和可中断的锁定等待）和提供更好的可伸缩性（竞争时的高性能）。大多数开发人员将不再直接使用 ReentrantLock 类，而是使用在 ReentrantLock 类上构建的高级类。
高级实用程序类。这些类实现并发构建块，每个计算机科学文本中都会讲述这些类 – 信号、互斥、闩锁、屏障、交换程序、线程池和线程安全集合类等。大部分开发人员都可以在应用程序中用这些类来替换许多同步、wait() 和 notify() 的使用，从而提高性能、可读性和正确性。

线程安全的类

首先它必须在单线程环境中正确运行。如果正确实现了类，那么说明它符合规范，对该类的对象的任何顺序的操作（公共字段的读写、公共方法的调用）都不应该：
- 使对象处于无效状态；
- 观察处于无效状态的对象；
- 违反类的任何变量、前置条件或后置条件。
而且，要成为线程安全的类，在从多个线程访问时，它必须继续正确运行，而不管运行时环境执行那些线程的调度和交叉，且无需对部分调用代码执行任何其他同步。
如果没有线程之间的某种明确协调，比如锁定，运行时可以随意在需要时在多线程中交叉操作执行。
在并发编程中，一种被普遍认可的原则就是：尽可能的使用不可变对象来创建简单、可靠的代码。

Thread

任何一个时刻，对象的控制权（monitor）只能被一个线程拥有。
无论是执行对象的wait、notify还是notifyAll方法，必须保证当前运行的线程取得了该对象的控制权（monitor）。
如果在没有控制权的线程里执行对象的以上三种方法，就会报java.lang.IllegalMonitorStateException异常。
JVM基于多线程，默认情况下不能保证运行时线程的时序性。

interrupt

当调用th.interrput()的时候，线程th的中断状态(interrupted status) 会被置位。我们可以通过Thread.currentThread().isInterrupted() 来检查这个布尔型的中断状态。
没有任何语言方面的需求要求一个被中断的程序应该终止。中断一个线程只是为了引起该线程的注意，被中断线程可以决定如何应对中断。这说明interrupt中断的是线程的某一部分业务逻辑，前提是线程需要检查自己的中断状态(isInterrupted())。
当th被阻塞的时候，比如被Object.wait, Thread.join和Thread.sleep三种方法之一阻塞时, 调用它的interrput()方法，可想而知，没有占用CPU运行的线程是不可能给自己的中断状态置位的, 这就会产生一个InterruptedException异常。

join

join方法可以让一个线程等待另一个线程执行完成。
若t是一个正在执行的Thread对象，t.join() 将会使当前线程暂停执行并等待t执行完成。重载的join()方法可以让开发者自定义等待周期。然而，和sleep()方法一样join()方法依赖于操作系统的时间处理机制，你不能假定join()方法将会精确的等待你所定义的时长。
如同sleep()方法，join()方法响应中断并在中断时抛出InterruptedException。

同步

同步的构造方法没有意义，因为当这个对象被创建的时候，只有创建对象的线程能访问它。
静态方法是和类（而不是对象）相关的，所以线程会请求类对象(Class Object)的内部锁。因此用来控制类的静态域访问的锁不同于控制对象访问的锁。
如果类中的两个域需要同步访问，但是两个域没有什么关联，那么可以为两个域个创建一个私有的锁对象，使两个域能分别同步。

锁

死锁描述了这样一种情景，两个或多个线程永久阻塞，互相等待对方释放资源。
饥饿是指当一个线程不能正常的访问共享资源并且不能正常执行的情况。这通常在共享资源被其他“贪心”的线程长期占用时发生
一个线程通常会有会响应其他线程的活动。如果其他线程也会响应另一个线程的活动，那么就有可能发生活锁。同死锁一样，发生活锁的线程无法继续执行, 然而线程并没有阻塞, 他们在忙于响应对方无法恢复工作。
wait方法，释放锁并挂起
如果在一个执行序列中，需要确定对象的状态，那么某个线程在执行这个序列时，需要获得所有这些对象的锁（如一来一回的相互鞠躬，必须保证不会同时鞠躬也不会同时静止）

线程安全集合

java.util.concurrent 包添加了多个新的线程安全集合类 ConcurrentHashMap, CopyOnWriteArrayList, CopyOnWriteArraySet
JDK 5.0 还提供了两个新集合接口 – Queue 和 BlockingQueue。Queue 接口与 List 类似，但它只允许从后面插入，从前面删除。BlockingQueue定义了一个先进先出的数据结构，当你尝试往满队列中添加元素，或者从空队列中获取元素时，将会阻塞或者超时。
ConcurrentMap是java.util.Map的子接口，定义了一些有用的原子操作。移除或者替换键值对的操作只有当key存在时才能进行，而新增操作只有当key不存在时才能进行, 使这些操作原子化，可以避免同步。ConcurrentMap的标准实现是ConcurrentHashMap，它是HashMap的并发模式。
ConcurrentNavigableMap是ConcurrentMap的子接口，支持近似匹配。ConcurrentNavigableMap的标准实现是ConcurrentSkipListMap，它是TreeMap的并发模式。
所有这些集合，通过在集合里新增对象和访问或移除对象的操作之间，定义一个happens-before的关系，来帮助程序员避免内存一致性错误。

CopyOnWrite

Vector 的常见应用是存储通过组件注册的监听器的列表。当发生适合的事件时，该组件将在监听器的列表中迭代，调用每个监听器。为了防止ConcurrentModificationException，迭代线程必须复制列表或锁定列表，以便进行整体迭代，而这两种情况都需要大量的性能成本。
CopyOnWriteArrayList及CopyOnWriteArraySet 类通过每次添加或删除元素时创建数组的新副本，避免了这个问题，但是进行中的迭代保持对创建迭代器时的副本进行操作。虽然复制也会有一些成本，但是在许多情况下，迭代要比修改多得多，在这些情况下，写入时复制要比其他备用方法具有更好的性能和并发性。

ConcurrentHashMap

Hashtable 和 synchronizedMap 所采取的获得同步的简单方法（同步 Hashtable 或者同步 Map 封装器对象中的每个方法）有两个主要的不足：
- 第一，这种方法对于可伸缩性是一种障碍，因为一次只能有一个线程可以访问 hash 表；
- 第二，这样仍不足以提供真正的线程安全性，许多公用的混合操作仍然需要额外的同步。虽然诸如 get() 和 put() 之类的简单操作可以在不需要额外同步的情况下安全地完成，但还是有一些公用的操作序列，例如迭代或者 put-if-absent（空则放入），需要外部的同步，以避免数据争用。
在大多数情况下，ConcurrentHashMap 是 Hashtable或 Collections.synchronizedMap(new HashMap()) 的简单替换。然而，其中有一个显著不同，即 ConcurrentHashMap 实例中的同步不锁定Map进行独占使用, 实际上，没有办法锁定 ConcurrentHashMap 进行独占使用，它被设计用于进行并发访问。为了使集合不被锁定进行独占使用，还提供了公用的混合操作的其他（原子）方法，如 put-if-absent。
ConcurrentHashMap 返回的迭代器是弱一致的，意味着它们将不抛出ConcurrentModificationException ，将进行 “合理操作” 来反映迭代过程中其他线程对 Map 的修改。

队列

Queue 接口比 List 简单得多，仅包含 put() 和 take() 方法，并允许比 LinkedList 更有效的实现。
Queue 接口还允许实现来确定存储元素的顺序。ConcurrentLinkedQueue 类实现先进先出（first-in-first-out，FIFO）队列。PriorityQueue 类实现优先级队列（也称为堆），它对于构建调度器非常有用，调度器必须按优先级或预期的执行时间执行任务。
实现 Queue 的类是：
- LinkedList 已经进行了改进来实现 Queue。
- PriorityQueue 非线程安全的优先级队列（堆）实现，根据自然顺序或比较器返回元素。
- ConcurrentLinkedQueue 快速、线程安全的、无阻塞 FIFO 队列。

弱一致的迭代器

java.util 包中的集合类都返回 fail-fast 迭代器，这意味着它们假设线程在集合内容中进行迭代时，集合不会更改它的内容。如果 fail-fast 迭代器检测到在迭代过程中进行了更改操作，那么它会抛出 ConcurrentModificationException，这是不可控异常。
java.util.concurrent 集合返回的迭代器称为弱一致的（weakly consistent）迭代器。对于这些类，如果元素自从迭代开始已经删除，且尚未由 next() 方法返回，那么它将不返回到调用者。如果元素自迭代开始已经添加，那么它可能返回调用者，也可能不返回。在一次迭代中，无论如何更改底层集合，元素不会被返回两次。

线程池

管理一大组小任务的标准机制是组合工作队列和线程池。工作队列就是要处理的任务的队列，前面描述的 Queue 类完全适合。线程池是线程的集合，每个线程都提取公用工作队列。当一个工作线程完成任务处理后，它会返回队列，查看是否有其他任务需要处理。如果有，它会转移到下一个任务，并开始处理。
线程池为线程生命周期间接成本问题和资源崩溃问题提供了解决方案。
- 通过对多个任务重新使用线程，创建线程的间接成本将分布到多个任务中。
- 作为一种额外好处，因为请求到达时，线程已经存在，从而可以消除由创建线程引起的延迟, 因此，可以立即处理请求，使应用程序更易响应。
- 而且，通过正确调整线程池中的线程数，可以强制超出特定限制的任何请求等待，直到有线程可以处理它，它们等待时所消耗的资源要少于使用额外线程所消耗的资源，这样可以防止资源崩溃。

Executor 框架

Executor 接口关注任务提交，确定执行策略。这使在部署时调整执行策略（队列限制、池大小、优先级排列等等）更加容易，更改的代码最少。
大多数 Executor 实现类还实现 ExecutorService接口，ExecutorService是Executor的子接口，它还管理执行服务的生命周期。这使它们更易于管理，并向生命可能比单独 Executor 的生命更长的应用程序提供服务。
执行策略定义何时在哪个线程中运行任务，执行任务可能消耗的资源级别（线程、内存等等），以及如果执行程序超载该怎么办。

ExecutorService

ExecutorService接口在提供了execute方法的同时，新加了更加通用的submit方法。
通过submit方法返回的Future对象可以读取Callable任务的执行结果，或管理Callable任务和Runnable任务的状态。
ExecutorService也提供了批量运行Callable任务的方法，ExecutorService还提供了一些关闭执行器的方法。

ScheduledExecutorService

ScheduledExecutorService扩展ExecutorService接口并添加了schedule方法。调用schedule方法可以在指定的延时后执行一个Runnable或者Callable任务。
ScheduledExecutorService接口还定义了按照指定时间间隔定期执行任务的scheduleAtFixedRate方法和scheduleWithFixedDelay方法。

Executors

Executors类包含用于构造许多不同类型的 Executor 实现的静态工厂方法：

newCachedThreadPool() 创建不限制大小的线程池，但是当以前创建的线程可以使用时将重新使用那些线程。如果没有现有线程可用，将创建新的线程并将其添加到池中。已有 60 秒钟未被使用的线程将其终止并从缓存中删除。
newFixedThreadPool(int n) 创建一个可重用固定线程数的线程池，以共享的无界队列方式来运行这些线程。如果在所有线程处于活动状态时提交附加任务，则在有可用线程之前，附加任务将在队列中等待。如果在关闭前的执行期间由于失败而导致任何线程终止，那么一个新线程将代替它执行后续的任务。
newSingleThreadExecutor() 创建一个单线程的线程池。这个线程池只有一个线程在工作，也就是相当于单线程串行执行所有任务, 此线程池保证所有任务的执行顺序按照任务的提交顺序执行。如果这个唯一的线程因为异常结束，那么会有一个新的线程来替代它。
newScheduledThreadPool(int n) 创建一个大小无限的线程池, 此线程池支持定时以及周期性执行任务的需求。
如果上面的方法都不满足需要，可以尝试ThreadPoolExecutor或者ScheduledThreadPoolExecutor。

定制 ThreadPoolExecutor

通过使用包含 ThreadFactory 变量的工厂方法或构造函数的版本，可以定义线程的创建。ThreadFactory 是工厂对象，其构造执行程序要使用的新线程。

public class DaemonThreadFactory implements ThreadFactory {
    public Thread newThread(Runnable r) {
        Thread thread = new Thread(r);
        thread.setDaemon(true);
        return thread;
    }
}

有时，Executor 不能执行任务，因为它已经关闭或者因为 Executor 使用受限制队列存储等待任务，而该队列已满。在这种情况下，需要咨询执行程序的RejectedExecutionHandler 来确定如何处理任务：

抛出异常（默认情况），
放弃任务，
在调用者的线程中执行任务，
或放弃队列中最早的任务以为新任务腾出空间。
setRejectedExecutionHandler可以设置拒绝的执行处理程序。

需要特别考虑的问题

如果应用程序对特定执行程序进行了假设，那么应该在 Executor 定义和初始化的附近对这些进行说明，从而使善意的更改不会破坏应用程序的正确功能。

一些任务可能同时等待其他任务完成。在这种情况下，当线程池没有足够的线程时，如果所有当前执行的任务都在等待另一项任务，而该任务因为线程池已满不能执行，那么线程池可能会死锁。
一组线程必须作为共同操作组一起工作。在这种情况下，需要确保线程池能够容纳所有线程。

调整线程池

如果线程池太小，资源可能不能被充分利用，在一些任务还在工作队列中等待执行时，可能会有处理器处于闲置状态。
另一方面，如果线程池太大，则将有许多有效线程，因为大量有效线程使用内存，或者因为每项任务要比使用少量线程有更多上下文切换，性能可能会受损。
Amdahl 法则提供很好的近似公式来确定线程池的大小：

用 WT 表示每项任务的平均等待时间，ST 表示每项任务的平均服务时间（计算时间）。则 WT/ST 是每项任务等待所用时间的百分比。对于 N 处理器系统，池中可以近似有 N*(1+WT/ST) 个线程。

Future 接口

Future 接口允许表示已经完成的任务、正在执行过程中的任务或者尚未开始执行的任务。通过 Future 接口，可以尝试取消尚未完成的任务，查询任务已经完成还是取消了，以及提取（或等待）任务的结果值。
FutureTask 类实现了 Future，并包含一些构造函数，允许将 Runnable 或 Callable和 Future 接口封装。因为 FutureTask 也实现 Runnable，所以可以只将 FutureTask 提供给 Executor。一些提交方法（如 ExecutorService.submit()）除了提交任务之外，还将返回 Future 接口。
Future.get() 方法检索任务计算的结果, 如果任务尚未完成，那么 Future.get() 将被阻塞直到任务完成；如果任务已经完成，那么它将立即返回结果; 如果任务完成，但有异常，则抛出 ExecutionException。

使用 Future 构建缓存

该示例利用 ConcurrentHashMap 中的原子 putIfAbsent() 方法，确保仅有一个线程试图计算给定关键字的值。如果其他线程随后请求同一关键字的值，它仅能等待（通过 Future.get() 的帮助）第一个线程完成。因此两个线程不会计算相同的值。

public class Cache<K,V> {
    private ConcurrentMap<K,FutureTask<V>> map = new ConcurrentHashMap<>();
    private Executor executor = Executors.newFixedThreadPool(8);

    static class Task<V> implements Callable<V>{
        @Override
        public V call() throws Exception {
            return null;
        }
    }

    public V get(final K key) throws ExecutionException, InterruptedException {
        FutureTask<V> ft = map.get(key);
        if (ft == null) {
            ft = new FutureTask(new Task());
            FutureTask<V> old = map.putIfAbsent(key, ft);
            if (old == null){
                executor.execute(ft);
            }else{
                ft = old;
            }
        }
        return ft.get();
    }
}

CompletionService

CompletionService 将执行服务与类似 Queue 的接口组合，从任务执行中删除任务结果的处理。CompletionService 接口包含用来提交将要执行的任务的 submit() 方法和用来询问下一完成任务的 take()/poll() 方法。
CompletionService 允许应用程序结构化，使用 Producer/Consumer 模式，其中生产者创建任务并提交，消费者请求完成任务的结果并处理这些结果。CompletionService 接口由 ExecutorCompletionService 类实现，该类使用 Executor 处理任务并从 CompletionService 导出 submit/poll/take 方法。
下列代码使用 Executor 和 CompletionService 来启动许多任务，并使用第一个生成的非空结果，然后取消其余任务：

<V> V solve(Executor e, Collection<Callable<V>> tasks) throws InterruptedException, ExecutionException {
    CompletionService<V> ecs = new ExecutorCompletionService<>(e);
    List<Future<V>> futures = new ArrayList<>();
    V result = null;

    try {
        tasks.forEach(p -> futures.add(ecs.submit(p)));
        for (int i = 0; i < tasks.size(); ++i) {
            V r = ecs.take().get();
            if (r != null) {
                result = r;
                break;
            }
        }
    } finally {
        for (Future<V> f : futures){
            f.cancel(true);
        }
    }

    return result;
}

Fork/Join

fork/join框架是ExecutorService接口的一种具体实现，目的是为了更好地利用多处理器带来的好处。它是为那些能够被递归地拆解成子任务的工作类型量身设计的。其目的在于能够使用所有可用的运算能力来提升你的应用的性能。
类似于ExecutorService接口的其他实现，fork/join框架会将任务分发给线程池中的工作线程。fork/join框架的独特之处在与它使用工作窃取(work-stealing)算法。完成自己的工作而处于空闲的工作线程能够从其他仍然处于忙碌(busy)状态的工作线程处窃取等待执行的任务。
fork/join框架的核心是ForkJoinPool类，它是对AbstractExecutorService类的扩展。ForkJoinPool实现了工作偷取算法，并可以执行ForkJoinTask任务。
在Java SE 8中，java.util.Arrays类的一系列parallelSort()方法就使用了fork/join来实现。这些方法与sort()系列方法很类似，但是通过使用fork/join框架，借助了并发来完成相关工作, 在多处理器系统中，对大数组的并行排序会比串行排序更快。
其他采用了fork/join框架的方法还有java.util.streams包中的一些方法，此包是Java SE 8发行版中Project Lambda的一部分。

同步工具

Semaphore

Semaphore 类实现标准 Dijkstra 计数信号。计数信号可以认为具有一定数量的许可权，该许可权可以获得或释放。如果有剩余的许可权，acquire() 方法将成功，否则该方法将被阻塞，直到其他线程释放release()许可权, 线程一次可以获得多个许可权。
计数信号可以用于限制有权对资源进行并发访问的线程数。该方法对于实现资源池或限制 Web 爬虫（Web crawler）中的输出 socket 连接非常有用。
注意信号不跟踪哪个线程拥有多少许可权, 这由应用程序来决定，以确保何时线程释放许可权，该信号表示其他线程拥有许可权或者正在释放许可权，以及其他线程知道它的许可权已释放。

互斥

计数信号的一种特殊情况是互斥，或者互斥信号。互斥就是具有单一许可权的计数信号，意味着在给定时间仅一个线程可以具有许可权, 互斥可以用于管理对共享资源的独占访问。
虽然互斥许多地方与锁定一样，但互斥还有一个锁定通常没有的功能，就是互斥可以由不具有许可权的其他线程来释放, 这在死锁恢复时会非常有用。

CyclicBarrier

CyclicBarrier 类可以帮助同步，它允许一组线程等待整个线程组到达公共屏障点。CyclicBarrier 是使用整型变量构造的，其确定组中的线程数。当一个线程到达屏障时（通过调用 CyclicBarrier.await()），它会被阻塞，直到所有线程都到达屏障，然后在该点允许所有线程继续执行。
CyclicBarrier可以重新使用, 一旦所有线程都已经在屏障处集合并释放，则可以将该屏障重新初始化到它的初始状态。还可以指定在屏障处等待时的超时；如果在该时间内其余线程还没有到达屏障，则认为屏障被打破，所有正在等待的线程会收到 BrokenBarrierException。
下列代码将创建 CyclicBarrier 并启动一组线程，每个线程在到达屏障点前会打印出自己的名字，等待其他线程到齐后，将执行CyclicBarrier绑定的Runnable，该Runnable在每个屏障点只执行一次。

    public static void main(String[] args){
        Runnable ready = new Runnable() {
            @Override
            public void run() {
                System.out.println("ready");
            }
        };

        CyclicBarrier cyclicBarrier = new CyclicBarrier(5, ready);

        ExecutorService executor = Executors.newCachedThreadPool();
        for (int i = 0; i < 5; i++) {
            Runnable task = new Runnable() {
                @Override
                public void run() {
                    try {
                        System.out.println(Thread.currentThread().getName());
                        cyclicBarrier.await();
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    } catch (BrokenBarrierException e) {
                        e.printStackTrace();
                    }
                }
            };
            executor.submit(task);
        }
        executor.shutdown();
    }

CountdownLatch

CountdownLatch 类与 CyclicBarrier 相似，因为它的角色是对已经在它们中间分摊了问题的一组线程进行协调。它也是使用整型变量构造的，指明计数的初始值，但是与 CyclicBarrier 不同的是，CountdownLatch 不能重新使用。
其中，CyclicBarrier 是到达屏障的所有线程的大门，只有当所有线程都已经到达屏障或屏障被打破时，才允许这些线程通过。CountdownLatch 将到达和等待功能分离，任何线程都可以通过调用 countDown() 减少当前计数，这种方式不会阻塞线程，而只是减少计数。await() 方法的行为与 CyclicBarrier.await() 稍微有所不同，调用 await() 任何线程都会被阻塞，直到闩锁计数减少为零，在该点等待的所有线程才被释放，对 await() 的后续调用将立即返回。
当问题已经分解为许多部分，每个线程都被分配一部分计算时，CountdownLatch 非常有用。在工作线程结束时，它们将减少计数，协调线程可以在闩锁处等待当前这一批计算结束，然后继续移至下一批计算。

public static void main(String[] args) throws InterruptedException {
    int concurrency = 5;
    ExecutorService executor = Executors.newCachedThreadPool();

    final CountDownLatch ready = new CountDownLatch(concurrency);
    final CountDownLatch start = new CountDownLatch(1);
    final CountDownLatch done = new CountDownLatch(concurrency);
    for(int i=0; i<concurrency; i++){
        executor.execute(new Runnable(){
            public void run(){
                ready.countDown();
                try {
                    start.await();
                    System.out.println(Thread.currentThread().getName() + "----done");
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                done.countDown();
            }
        });
    }
    ready.await();
    System.out.println("all threads are ready");
    start.countDown();
    done.await();
    System.out.println("all threads finished");
    executor.shutdown();
}

Exchanger

Exchanger 类方便了两个共同操作线程之间的双向交换，就像具有计数为 2 的 CyclicBarrier，并且两个线程在都到达屏障时可以”交换”一些状态。（Exchanger 模式有时也称为聚集。）
Exchanger 通常用于一个线程填充缓冲（通过读取 socket），而另一个线程清空缓冲（通过处理从 socket 收到的命令）的情况。当两个线程在屏障处集合时，它们交换缓冲。
下列代码说明了这项技术：

public static void main(String[] args){
    Exchanger<String> exchanger = new Exchanger<>();
    ExecutorService executor = Executors.newCachedThreadPool();

    Runnable producer = new Runnable() {
        @Override
        public void run() {
            for (int i = 0; i < 5; i++) {
                try {
                    String data = "produce";
                    System.out.println(Thread.currentThread().getName() + "-offer----" + data);
                    exchanger.exchange(data);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }
    };

    Runnable consumer = new Runnable() {
        @Override
        public void run() {
            for (int i = 0; i < 5; i++) {
                try {
                    String data = exchanger.exchange(null);
                    System.out.println(Thread.currentThread().getName() + "-get----" + data);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }

            }
        }
    };

    executor.execute(producer);
    executor.execute(consumer);
    executor.shutdown();
}

Lock工具

Lock 接口将内置监视器锁定的行为普遍化，允许多个锁定实现，同时提供一些内置锁定缺少的功能，如计时的等待、可中断的等待、锁定轮询、每个锁定有多个条件等待集合以及无阻塞结构的锁定。
java.util.concurrent.locks包提供了复杂的锁, 锁对象作用非常类似同步代码使用的隐式锁, 每次只有一个线程可以获得锁对象。通过关联Condition对象，锁对象也支持wait/notify机制。
锁对象之于隐式锁最大的优势在于，它们有能力收回获取锁的尝试（如果获取锁失败，将不会继续请求，以免发生死锁）。如果当前锁对象不可用，或者锁请求超时（如果超时时间已指定），tryLock方法会收回获取锁的请求。如果在锁获取前，另一个线程发送了一个中断，lockInterruptibly方法也会收回获取锁的请求。

ReentrantLock

ReentrantLock 是具有与隐式监视器锁定（使用 synchronized 方法和语句访问）相同的基本行为和语义的 Lock 的实现，但它具有扩展的能力。
在竞争条件下，ReentrantLock 的实现要比现在的 synchronized 实现更具有可伸缩性。这意味着当许多线程都竞争相同锁定时，使用 ReentrantLock 的吞吐量通常要比 synchronized 好。
虽然 ReentrantLock 类有许多优点，但是与同步相比，它有一个主要缺点 – 它可能忘记释放锁定。因为锁定失误（忘记释放锁定）的风险，所以对于基本锁定，强烈建议继续使用 synchronized，除非真的需要 ReentrantLock 额外的灵活性和可伸缩性。
建议当获得和释放 ReentrantLock 时使用下列结构：

Lock lock = new ReentrantLock();
...
lock.lock();
try {
  // perform operations protected by lock
}
catch(Exception ex) {
 // restore invariants
}
finally {
  lock.unlock();
}

Condition

就像 Lock 接口是同步的具体化，Condition 接口是 Object 中 wait() 和 notify() 方法的具体化。Lock 中的一个方法是 newCondition()，它要求该锁定返回新的 Condition 对象限制。
await()、signal() 和 signalAll() 方法类似于 wait()、notify() 和 notifyAll()，但增加了灵活性，每个 Lock 都可以创建多个条件变量。这简化了一些并发算法的实现。

ReadWriteLock

ReentrantLock 实现的锁定规则非常简单 – 每当一个线程具有锁定时，其他线程必须等待，直到该锁定可用。
有时，当对数据结构的读取通常多于修改时，可以使用更复杂的称为读写锁定的锁定结构，它允许有多个并发读者，同时还允许一个写入者独占锁定。该方法在一般情况下（只读）提供了更大的并发性，同时在必要时仍提供独占访问的安全性。
ReadWriteLock 接口和 ReentrantReadWriteLock 类提供这种功能 – 多读者、单写入者锁定规则，可以用这种功能来保护共享的易变资源。

原子变量

java.util.concurrent.atomic包定义了对单一变量进行原子操作的类。所有的类都提供了get和set方法，可以使用它们像读写volatile变量一样读写原子类。就是说，同一变量上的一个set操作对于任意后续的get操作存在happens-before关系。原子的compareAndSet方法也有内存一致性特点，就像应用到整型原子变量中的简单原子算法。
即使大多数用户将很少直接使用它们，原子变量类（AtomicInteger、AtomicLong、AtomicReference 等等）也有充分理由是最显著的新并发类。这些类公开对 JVM 的低级别改进，允许进行具有高度可伸缩性的原子读-修改-写操作。大多数现代 CPU 都有原子读-修改-写的原语，比如比较并交换（CAS）或加载链接/条件存储（LL/SC）。原子变量类使用硬件提供的最快的并发结构来实现。
几乎 java.util.concurrent 中的所有类都是在 ReentrantLock 之上构建的，ReentrantLock 则是在原子变量类的基础上构建的。所以，虽然仅少数并发专家使用原子变量类，但 java.util.concurrent 类的很多可伸缩性改进都是由它们提供的。
原子变量主要用于为原子地更新 “热” 字段提供有效的、细粒度的方式， “热” 字段是指由多个线程频繁访问和更新的字段。另外，原子变量还是计数器或生成序号的自然机制。

并发随机数

在JDK7中，java.util.concurrent包含了一个相当便利的类，ThreadLocalRandom，当应用程序期望在多个线程或ForkJoinTasks中使用随机数时。
对于并发访问，使用TheadLocalRandom代替Math.random()可以减少竞争，从而获得更好的性能。
只需调用ThreadLocalRandom.current()，然后调用它的其中一个方法去获取一个随机数即可。

性能与可伸缩性

性能是 “可以快速执行此任务的程度” 的评测。可伸缩性描述应用程序的吞吐量如何表现为它的工作量和可用计算资源增加。
可伸缩的程序可以按比例使用更多的处理器、内存或 I/O 带宽来处理更多个工作量。当我们在并发环境中谈论可伸缩性时，我们是在问当许多线程同时访问给定类时，这个类的执行情况。
java.util.concurrent 中的低级别类 ReentrantLock 和原子变量类的可伸缩性要比内置监视器（同步）锁定高得多。因此，使用 ReentrantLock 或原子变量类来协调共享访问的类也可能更具有可伸缩性。

乱码现象分析

Sat, 05 Apr 2014 00:00:00 +0000

我们知道，web浏览器会将form中的内容打包成HTTP请求体，然后发送到服务端，服务端对请求体解析后可以得到传递的数据。这当中包含两个过程：encode与decode。

HTTP
UrlEncode
UrlDecode
方案

HTTP

我们使用ServerSocket搭建一个小服务器来看清http请求的全貌, 该服务器只有一个功能, 就是打印请求体。

public class HttpPrint {
    private ServerSocket serverSocket;

    public HttpPrint() throws IOException {
        serverSocket = new ServerSocket(8080);
    }

    public void show() throws IOException{
        while(true){
            Socket socket = serverSocket.accept();
            byte[] buf = new byte[1024];
            InputStream is =  socket.getInputStream();
            ByteArrayOutputStream os = new ByteArrayOutputStream();
            int n = 0;
            while ((n = is.read(buf)) > -1){
                os.write(buf,0,n);
            }
            os.close();
            is.close();
            socket.close();
            System.out.println(os);
        }
    }

    public static void main(String[] args) throws IOException {
        new HttpPrint().show();
    }
}

用html页面来发送get与post请求

<a href="http://localhost:8080/hsp?param=你好全世界">Test</a>
<form action="http://localhost:8080/hsp" method="post">
   <input type="text" name="param" value="你好全世界"/>
   <input type="submit"/>
</form>

启动服务器后，查看打印内容，在我的机器上，请求内容如下:

get

post

从post中的Content-Type:application/x-www-form-urlencoded可以看到，虽然数据为中文，但是在传递的时候，经过了一次urlEncode，这样一来，在数据交换层面就可以屏蔽编码的不一致性。

UrlEncode

urlEncode的任务是将form中的数据进行编码, 编码过程非常简单, 任何字符只要不是ASCII码, 它们都将被转换成字节形式, 每个字节都写成这种形式：一个 “%” 后面跟着两位16进制的数值。 urlEncode只能识别ASCII码，可以想象的是，那些urlEncode不能识别的字符，也就是十六进制数，一定是依赖于特定的字符集产生的, 字符集包括unicode,iso等。

那么浏览器用的是什么字符集呢? 答案是：默认与contentType相同, form可以通过属性accept-charset指定。

例如我们通常可以在jsp中看到这样的设置:

<%@page contentType="text/html;charset=UTF-8" %>

或者在html中这样设置:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

这表示浏览器得到响应流之后，用contentType指定的字符集，将流中的字节转换为字符，同样地，也会用这个字符集将页面中字符转换为字节。

关于浏览器设定字符集的问题，我们不过多讨论，现在只需要知道有这么个过程就行了, 需要注意的是，无论浏览器使用什么字符集，服务端都是无法获知的。这里需要换位考虑一下，浏览器是一个客户端，应该让客户端 “迁就” 服务端, 所以浏览器请求一个服务的时候，应该让浏览器考虑服务端支持什么字符集, 得到了响应后, 用服务端告诉浏览器的字符集进行解析。

UrlDecode

现在我们将目光转向Servlet, 并使用上面的html来请求服务，请确保请求的字符集为unicode, 应用服务器使用tomcat6。

public class HttpServletPrint extends HttpServlet{
    @Override
    protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        System.out.println(req.getParameter("param"));
    }

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        this.doPost(req,resp);
    }
}

get与post结果如下，果然如预料中乱码了。

现在我们从Servlet中看看请求体, 修改上面的Servlet代码如下：

public class HttpServletPrint extends HttpServlet{
    @Override
    protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        //System.out.println(req.getParameter("param"));
        byte[] buf = new byte[1024];
        int n = 0;
        ByteArrayOutputStream bos = new ByteArrayOutputStream();
        InputStream is = req.getInputStream();
        while ((n = is.read(buf, 0, buf.length))>-1){
            bos.write(buf, 0, n);
        }
        String param = bos.toString();
        String s = URLDecoder.decode(param,"utf-8");
        System.out.println(s);
    }

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        this.doPost(req,resp);
    }
}

get与post结果如下,Servlet将http头部解析完成后，将请求体留了下来供应用程序使用, 这是考虑到http请求可能有多种 enctype , 请求体的结构可能不同, 例如，multipart/form-data就不是这样的key=value结构，关于multipart/form-data，我在这篇 fileupload 中曾有过简要分析。

从图中可以看到, 设置了正确的字符集后, 服务端将能够正确地解析, get部分什么都没有，这是因为get没有请求体。

让我们换种字符集试试, 比如, 将servet中的”utf-8”换成”iso-8859-1”。

嘿，果然如我所料，而且这个字符串好像很眼熟，和req.getParameter(“param”)结果是一样的，没错，事实上，tomcat默认的字符集就是iso-8859-1, 我们从中可以得到一个推论，tomcat使用默认的字符集，对http请求进行过一次decode。

方案

urlDecode的任务是将请求中的百分号码转换成字符，显而易见的是，使用与urlEncode时相同的字符集才能成功转换。通常的做法是，让服务端支持涵盖多国语言的”utf-8”，然后让客户端也用”utf-8”请求服务。

指定服务端字符集的方式有两种，一是修改应用服务器的默认编码，二是添加一个过滤器进行编码转换, 方法一最方便, 但是影响了程序的可移植性, 方法二可移植, 它只需要做一件事:requet.setCharacterEncoding("UTF-8");, 实际上，该过滤器并没有进行任何编码转换的工作，它仅仅只是一个配置，该配置项将被后续程序使用，这些后续程序包括web服务器内置的解析程序，以及第三方解析工具等。

需要注意的是，requet.setCharacterEncoding(“UTF-8”);，只对请求体有效，也就是说，请求头不归它管，而是由web服务器采用自己配置的字符编码进行解析，此时如果url中包含中文（如get请求的参数），那么将不可避免地出现字符丢失。解决办法是在客户端对url进行encodeURI两次, 然后再在服务端URLDecoder.decode(param,"utf-8");。

为什么要 encodeURI 两次？talk is cheap， let’s code！

注意观察这张图片，从中发现了什么? 没错，第一次encodeURI生成了HTTP一节的示例中一样的结果。我们在浏览器窗口中输入 “http://localhost:8080/hsp?param=%E4%BD%A0%E5%A5%BD%E5%85%A8%E4%B8%96%E7%95%8C”, 会发现它变成了 “http://localhost:8080/hsp?param=你好全世界”, 在url里，浏览器认为%是个转义字符，浏览器会把%与%之间的编码，两位两位取出后进行decode, 也就是变回 “你好全世界”, 然后再用这个url发送请求, 最终实际发送的内容实际上还是%E4%BD%A0%E5%A5%BD%E5%85%A8%E4%B8%96%E7%95%8C。换言之，以明文传递的这种url会被浏览器否决一次，再换言之，在js中进行一次encodeURI等于什么都没做。

再注意观察第2和第3个输出，有什么规律? 是的，从第二次开始encodeURI只是将%变成了%25，根据我们刚才总结出的规律可知，在encodeURI两次的情况下，最后发送到浏览器中的数据为%25E4%25BD%25A0%25E5%25A5%25BD%25E5%2585%25A8%25E4%25B8%2596%25E7%2595%258C, 理所当然的，web服务器将使用默认的字符集对其decode, 然而, 无论选择哪种字符集, 将%25转换成%总是不会出错的, decode之后，%E4%BD%A0%E5%A5%BD%E5%85%A8%E4%B8%96%E7%95%8C 将完整地送到Servlet手上。

System.out.println(URLDecoder.decode(req.getParameter("param"),"utf-8"));

window.location.href="http://localhost:8080/hsp?param=" + encodeURI(encodeURI('你好全世界'));

解析HTTP, 实现文件上传

Sat, 15 Mar 2014 00:00:00 +0000

HTTP
分析
设计
关键代码
源码获取

本文的目的是简要说明如何编写一个文件上传组件，使他的功能类似 commons-fileupload, 并在结尾处提供了完整代码的获取方式。

HTTP

本文讨论的是基于 HTTP 协议的文件上传，下面先来看看 HTTP 请求的真面目。

首先，用 JavaSe 类库中的 Socket 搭建一个超简单的服务器，这个服务器只有一个功能，就是完整地打印整个 HTTP 请求体。

public class Server {

    private ServerSocket serverSocket;

    public Server() throws  IOException{
        serverSocket = new ServerSocket(8080);
    }

    public void show() throws IOException{
        while(true){
            Socket socket = serverSocket.accept();
            byte[] buf = new byte[1024];
            InputStream is =  socket.getInputStream();
            OutputStream os = new ByteArrayOutputStream();
            int n = 0;
            while ((n = is.read(buf)) > -1){
                os.write(buf,0,n);
            }
            os.close();
            is.close();
            socket.close();

            System.out.println(os);
        }
    }

    public static void main(String[] args) throws IOException {
        new Server().show();
    }

}

将服务器运行起来之后，在浏览器中输入地址：http://localhost:8080

在我的机器上，显示如下内容，可以看到，这个一个get请求

下面利用一个 html 的 form表单提交 post 请求

    <form action="http://localhost:8080" method="post" enctype="multipart/form-data">
       <input type="text" name="time" value="1970-01-01"/>
        <input type="file" name="file"/>
        <input type="submit"/>
    </form>

在我的机器上，显示如下内容

注意图中被红色框起来的部分，第一个红框指示了本次请求中，用来分隔不同元素的分隔线。

每个元素将以此分隔线作为第一行，后面紧跟对元素的描述，描述与内容用空行分隔。

分隔线的后面加两个小短横代表整个请求体结束，即EOF。

我们需要做的工作，就是利用分隔线，从请求体中分离出每个元素，分析HTTP请求头的工作可以交给Servlet。

分析

那么，如何分离呢？

java中的 InputStream 只能读取一次，所以我们想要方便地分析一个流，最直接的办法就是将其缓存下来。

RandomAccessFile 或许能够满足需求，RandomAccessFile 可以提供一个指针用于在文件中的随意移动，然而需要读写本地文件的方案不会是最优方案。

先将整个流读一遍将内容缓存到内存中？这种方案在多个客户端同时提交大文件时一定是不可靠的。

最理想的方案可能是，我只需要读一遍 InputStream , 读完后将得到一个有序列表，列表中存放每个元素对象。

很明显，JavaSe的流没有提供这个功能

我们知道从 InputStreeam 中获取内容需要使用 read 方法，返回 -1 表示读到了流的末尾，如果我们增强一下read的功能，让其在读到每个元素末尾的时候返回 -1，这样不就可以分离出每个元素了吗，至于判断是否到了整个流的末尾，自有办法。

设计

如何增强read方法呢？

read方法要在读到元素末尾时返回-1 , 一定需要先对已读取的内容进行分析，判断是否元素末尾。

我的做法是，内部维护一个buffer，read方法在读取时先将字节写入到这个buffer中，然后分析其中是否存在分隔线，然后将buffer中可用的元素复制到客户端提供的buffer。

这个内部维护的buffer并不总是满的，其中的字节来自read方法的原始功能，所以我们需要一个变量来记录buffer中有效字节的末尾位置 tail。

我们还需要一个变量 pos 来标记buffer中是否存在分隔线，pos的值即为分隔线的开头在buffer中的位置，如果buffer中不存在分隔线pos的值将为-1。

但是问题没这个简单，分隔线在buffer中存在状态有两种情况：

情况A，分隔线完好地存在于buffer中，图中的bundary即为分隔线

情况B，分隔线的一部分存在于buffer中

在B情况下，boundary有多少字节存在于buffer中是不确定的，而且依靠这些不完整的字节根本无法判断他是否属于boundary开头。

例如，buffer中没有发现boundary，但是buffer末尾的3个字节与boundary开头相同，这种情况可能只是巧合，boundary并没有被截断。

对于这个问题，有一个解决办法，我们不必检查到buffer末尾，而是在buffer末尾留一个关健区pad。

这个关健区中很有可能存在被截断boundary，每次检查到pad开头时立即收手，此位置之前的数据可以确保没有boundary，在下次填充buffer时，将这个关健区中的数据复制到buffer开头再处理。很显然，关健区pad长度应该等于boundary，如图：

关键代码

在buffer中检查boundary

private int findSeparator() {
    int first;
    int match = 0;
    //若buffer中head至tail之间的字节数小于boundaryLength,那么maxpos将小于head,循环将不会运行,返回值为-1
    int maxpos = tail - boundaryLength;
    for (first = head; first <= maxpos && match != boundaryLength; first++) {
        first = findByte(boundary[0], first);
        if (first == -1 || first > maxpos) {
            return -1;
        }
        for (match = 1; match < boundaryLength; match++) {
            if (buffer[first + match] != boundary[match]) {
                break;
            }
        }
    }
    if (match == boundaryLength) {
        return first - 1;
    }
    return -1;
}

填充buffer

private int makeAvailable() throws IOException {
    //该方法在available返回0时才会被调用,若pos!=-1那pos==head,表示boundary处于head位,可用字节数为0
    if (pos != -1) {
        return 0;
    }

    // 将pad位之后的数据移动到buffer开头
    total += tail - head - pad;
    System.arraycopy(buffer, tail - pad, buffer, 0, pad);

    // 将buffer填满
    head = 0;
    tail = pad;
    //循环读取数据,直至将buffer填满,在此过程中,每次读取都将检索buffer中是否存在boundary,无论存在与否,都将即时返回可用数据量
    for (;;) {
        int bytesRead = input.read(buffer, tail, bufSize - tail);
        if (bytesRead == -1) {
            //理论上因为会对buffer不断进行检索,读到boundary时就会return 0,read方法将返回 -1,
            //所以不会读到input末尾,如果运行到了这里,表示发生了错误.
            final String msg = "Stream ended unexpectedly";
            throw new RuntimeException(msg);
        }
        if (notifier != null) {
            notifier.noteBytesRead(bytesRead);
        }
        tail += bytesRead;
        findSeparator();
        //若buffer中的数据量小于keepRegion(boundaryLength),av将必定等于0,循环将继续,直至数据量大于或等于keepRegion(boundaryLength).
        //此时将检索buffer中是否包含boundary,若包含,将返回boundary所在位置pos之前的数据量,若不包含,将返回pad位之前的数据量
        int av = available();

        if (av > 0 || pos != -1) {
            return av;
        }
    }
}

强化后的read方法

@Override
public int read(byte[] b, int off, int len) throws IOException {
    if (closed) {
        throw new RuntimeException("the stream is closed");
    }
    if (len == 0) {
        return 0;
    }
    int res = available();
    if (res == 0) {
        res = makeAvailable();
        if (res == 0) {
            return -1;
        }
    }
    res = Math.min(res, len);
    System.arraycopy(buffer, head, b, off, res);
    head += res;
    total += res;
    return res;
}

源码获取

我已经按照这套想法完整地实现了文件上传组件

有兴趣的朋友可以从我的Gighub获取源码点我获取

使用方法：点我查看

Effective Java

Tue, 26 Nov 2013 00:00:00 +0000

一 创建和销毁对象
二 通用方法
三 类和接口
四 泛型
五 枚举和注解
六 方法
七 通用程序设计
八 异常
十 序列化

`一` 创建和销毁对象

`1`.考虑用静态工厂方法代替构造器

静态工厂方法的优势：

1.有名称，可以见名知义了解获取对象的特点

2.不必每次调用时都创建一个对象

3.可以返回原类型的任何子类型对象

4.创建参数化类型实例时，可以使代码更简洁(右边无需再写一遍)

5.不可变对象可以进行缓存，以提升性能

`2`.遇到多个构造器参数时要考虑用构建器

构建器优势：

1.重叠构造器代码冗余

2.JavaBean模式阻止了将类做成不可变的可能

3.builder可以进行参数检查

4.无论创建多少个对象，builder只需要一个，且可以在创建不同对象时进行调整，或者自动填充某些域。

不足：创建对象前需要先创建builder

`3`.用私有构造器或者枚举类型强化Singleton属性

不使用枚举时：

1.构造器私有

2.构造器抛出异常 if(INSTANCE!=null) throw

3.序列化时必须声明所有实例域都是瞬时（transient）的，并提供一个readResolve方法返回现有的单例

`4`.通过私有构造器强化不可实例化的能力

并在构造器中抛出异常

`5`.避免创建不必要的对象

1.如果对象是不可变的,将始终可以重用

2.对于给定对象的适配器,不需要创建多个实例,例如:对于同一Map对象的keySet方法,每次返回的都是同一个对象

3.优先使用基本类型,而不是装箱类型

4.通过维护对象池来避免创建对象并不是好主意,除非对象非常昂贵(数据库连接池).

`6`.消除过期的对象引用

内存泄露常见来源：

1.无意识的对象保持(只要是类自己管理内存，程序员就应该警惕内存泄露问题)

2.被遗忘在缓存中的对象引用(考虑用WeakHashMap实现缓存)

3.监听器和其他回调没有显式地取消注册

4种引用：

1.强引用 Object obj = new Object();：只要强引用还存在，GC永远不会回收

2.软引用 SoftReference：用来描述一些有用但不必需的对象，在系统将要发生内存溢出之前，GC会对软引用对象进行回收，若回收后仍没有足够内存，才会抛出异常。

3.弱引用 WeakReference：也是用来描述非必需对象的，但是强度比软引用更弱，弱引用对象只能生存到下一次GC发生之前，当GC工作时，无论内存是否足够，都会回收弱引用对象

4.虚引用 PhantomReference：也称为幽灵引用或幻影引用，是最弱的一种引用关系。一个对象是否有虚引用存在，完全不会对其生存时间构成影响，也无法通过虚引用来获得一个实例。为对象设置一个虚引用的唯一目的就是能在这个对象被GC回收时收到一个系统通知。

`7`.避免使用终结方法

1.终结方法不能保证会被及时执行，也不能保证会被执行，所以不应该依赖终结方法来更新重要的持久状态

2.终结方法中发生的异常不会使线程终止，也不会打印栈轨迹，对象将处于破坏状态

3.终结方法有非常严重的性能损失

4.如果需要终止资源，应该显式地提供终止方法(io中的close方法)，通常与try-finally结合使用，以确保及时终止

注意：

1.除非作为安全网或者终止非关键资源，否则不要使用终结方法，最好就当没这个方法

2.如果使用了终结方法，要记住super.finalize

3.如果终结方法作为安全网，要记录终结方法的非法用法

4.如果终结方法所属的类不是final的，请考虑使用终结方法守卫者

`二` 通用方法

`8`.覆盖equals时请遵守通用约定

必须遵守自反性、对称性、传递性、一致性、非空性

可以用&&连接所有对field的比较结果使代码简洁

诀窍:

1.先使用== 操作符比较以优化性能

2.使用instanceof检查类型是否正确可以同时搞定null判断

3.只比较关键域,可以通过关键域计算出来的冗余域不需要比较

4.优先比较最可能不同、开销最低的域

5.对float,double用compare特殊处理，对数组用Arrays.equals处理

6.覆盖equals时总要覆盖hashCode

7.不要企图让equals太智能，不需要考虑参数可能存在的等价关系

8.不要修改equals方法的参数类型(修改了就不是覆盖了),@Override可以避免这一点

9.里氏替换原则

10.优先用组合+公有视图的方式扩展值组件，而不是用继承

`9`.覆盖equals时总要覆盖hashCode

1.相同的对象必须具有相同的hashCode(在hash表中,hashCode用来定位hash bucket,如果相等的对象有不同的hashCode,那么hash表将从错误的hash bucket中寻找对象,最后会判定为不存在)

2.用result = 31 * result + c的方式获取hashCode，result初值设为17，c为每个域的散列值

3.能够通过关键域计算出来的冗余域可以排除

4.如果计算hashCode开销很大，可以对hashCode进行缓存，并在hashCode方法第一次被访问时才进行计算

5.不要试图排除关键域(equals用到的所有域)来提高性能，这样虽然会提高hashCode计算速度，但是会提高hashCode重复率，反而降低散列性能。

`10`.始终要覆盖toString

1.优点：易于阅读，易于调试，易与其他应用交换数据

2.提供一个静态工厂用于将toString返回值转换为本身的类型

3.在文档中明确表示是否规定了toString的格式，如果规定了格式就要严格遵守

4.对toString返回值中包含的关键内容提供访问方法

`11`.谨慎地覆盖clone

1.实现Cloneable接口(空接口)需要提供一个public clone(Object中声明为proteced)方法

2.从jdk1.5开始，引入了协变返回类型，clone方法被覆盖后可以返回Object的子类型（通则：永远不要让客户去做任何类库能完成的事情）

3.clone方法就是另一个构造器；必须确保它不会伤害到原始对象，并确保正确地创建被克隆对象中的约束条件。

4.clone架构与引用可变对象的final域的正常用法是不相兼容的，为了使类可clone，有时需要去掉一些final

5.使用深拷贝，递归地调用每个域中包含的域，一直深入到不可变类为止

6.拷贝”长”对象(数组，链表等)时，如果使用递归会创建很多指针消耗栈空间，可以考虑换成迭代

7.另一种方法：先调用super.clone()，将所有域设为0值，然后为其赋值新对象。这种方法简单合理，但是没有”直接操作对象及其域中对象的clone方法“快。

8.clone过程中不应该调用任何非final方法(如果是private方法则不需要final)，因为子类有机会改变该方法的行为。

9.重写的public clone方法应该忽略CloneNotSupportedException，但如果

该类是用来被继承的，则应该模拟Object.clone：声明为protected，抛出异常，不实现Cloneable。

10.对于不可变类，提供clone没有太大意义

11.用拷贝构造器(即参数类型为类本身的构造器)或者拷贝工厂代替clone，可以增加一个参数实现克隆对象的转型（例如接受一个Collection参数与一个Class参数）

`12`.考虑实现Comparable接口

1.可以方便地使用各种泛型算法与Comparable的集合实现

2.强烈建议(x.compareTo(y) == 0) == (x.equals(y))，但非必须，若违反了这个条件，应该予以说明。

3.不满足上一条约定的对象放入有序集合(使用compareTo，如TreeSet)中后，将无法遵守集合接口通用(使用equals)约定（如BigDecimal，浮点数）

4.优先用组合+公有视图的方式扩展值组件，而不是用继承(同equals)

5.Comparable只规定了符号，没有规定数值大小，可以直接返回两个数值相减的结果，但是要小心溢出

`三` 类和接口

`13`.使类和成员的可访问性最小化

1.实例域决不能是公有的

2.静态公共域只能为final修饰的基本类型或者final修饰的不可变类

3.用Collections.unmodifiableList(arr)

将数组变成不可变列表后再提供访问；或者在访问方法中返回数组的clone()

`14`.在公有类中使用访问方法而非公有域

暴露域将失去内部表示法的灵活性，也将失去对数据访问进行限制的能力

`15`.使可变性最小化

1.创建不可变类的5条规则

(1).不要提供任何会修改对象状态的方法

(2).保证类不会被扩展(final或者构造器私有)

(3).使所有域都是final的

(4).使所有域成为私有的

(5).确保对于任何可变组件的互斥访问

2.用公有的静态域或静态工厂为不可变类提供缓存

3不可变对象本质上是线程安全的，它们不要求同步，可以被自由地共享，永远不需要保护性拷贝，不需要拷贝构造器

4.不可变类可以共享内部信息

5.不可变对象为其他对象提供了大量的构件

6.不可变类的缺点：每一个不同的值都需要一个单独的对象，存在性能问题，可以提供1个配套类来进行过渡操作(如StringBuilder)

7.因历史问题没有设置成final的不可变类(如BigInteger)，在使用时需要检查对象是否被扩展了，如果被扩展了就可能需要保护性拷贝

8.如果实现Serializable，必须显式地提供readObject和readResolve方法或者使用ObjectOutputStream.writeUnshared和ObjectInputStream.readUnshared方法

9.除非有必须的理由让类可变，否则类应该是不可变的；如果类无法做成不可变的，也应该尽力限制其可变性。因此域也应该是final的。

`16`.复合优先于继承

1.继承破坏了封装性，子类依赖于父类的实现细节，若父类内部发生变动，将可能损坏子类。

2.假设子类覆盖父类所有的方法，增加了对参数的类型检查；后来父类增加了新方法，而子类没有同步更新，非法的参数将有可能通过类型检查，这将会产生安全漏洞

3.假设子类增加了新方法，后来父类也新增了1个签名相同但返回类型不同的方法，编译将不通过；如果方法签名与返回类型都相同，将形成覆盖，又回到了上一种情况

4.复合/转发的类称为组件，并实现相同接口的类为包装类，每个接口只需要1个转发类

5.包装类不适用于回调框架，回调函数传递是1个指向自身的引用，避开了外面的包装类

6.继承会将api中所有缺陷传播到子类中去，而复合却可以设计新的api隐藏缺陷

7.只有真正存在从属关系时，才应该使用继承

`17`.要么为继承而设计，并提供文档说明，要么就禁止继承

1.决不能在构造器中调用可以被覆盖的方法，否则这样的方法将会在子类构造器之前运行，若是该方法中存在对域的访问，将会造成空指针异常

2.类必须提供适当的hook，以便能够进入子类的内部工作流程

3.如果实现了Cloneable或Serializable接口，那么clone与readObject都不能调用可被覆盖的方法

4.如果实现了Serializable接口，必须使readObject与writeReplace成为受保护的方法，否则它们将会被子类忽略掉

5.如果必须让类可被继承，务必保证这个类永远不会调用可覆盖方法，可以机械地消除可覆盖方法的自用性：将每个可覆盖方法的方法体移到一个私有的“辅助方法中”，然后让可覆盖方法调用辅助方法实现功能，这样可以确保可覆盖方法永远不会干涉到父类的运行。

`18`.接口优于抽象类

1.现有的类易被更新，以实现新的接口

2.接口是定义mixin（混合类型）理想选择

3.接口允许我们构造非层次接口的类型框架

4.在包装类模式下，接口使得安全地增强类的功能成为可能

5.通过对导出的每个接口都提供一个骨架实现（skeletal implementation）类，把接口和抽象类的优点结合起来

6.实现了接口的类可以把对于接口方法的调用转发到一个内部私有类的实例上，这个内部私有类扩展了骨架实现类，这种方法被称为“多重模拟继承”。

7.抽象类比接口更易于扩展，抽象类可以直接增加方法，接口却不可以。

8.接口一旦被公开发行，并且已被广泛实现，再想改变接口是不可能的。

9.接口通常是定义允许多个实现的类型的最佳途径，但是当演变的容易性比灵活性和功能性更重要时例外。

`19`.接口只用于定义类型

1.常量接口模式是对接口的不良使用

2.如果这些常量最好被看作枚举类型的成员，就应该是枚举类型，否则应该使用不可实例化的工具类来导出这些常量。

3.如果大量利用工具类来导出常量，可以通过利用静态导入机制，避免用类名来修饰常量名。（1.5版本后）

`20`.类层次优于标签类

1.标签类过于冗长，容易出错，并且效率低下

2.编译器确保每个类的构造器都初始化它的数据域，对于根类中声明的每个抽象方法，都确保有一个实现。

3.类层次的另一种好处在于，它们可以用来反映类型之间本质上的层次关系，有助于增强灵活性，并进行更好的编译时类型检查。

`21`.用函数对象表示策略

1.如果一个类仅仅导出一个方法，它的实例实际上就等同于一个指向该方法的指针。

2.设计具体的策略类时，还需要定义一个策略接口

3.如果它被重复执行，考虑将函数对象存储到一个私有的静态final域里，并重用它。

4.宿主类可以导出公有的静态域（或静态工厂方法），其类型为策略接口，具体的策略类可以是宿主类的私有嵌套类。

`22`.优先考虑静态成员类

1.嵌套类存在的目的应该只是为它的外围类提供服务。

2.嵌套类有四种：静态成员类，非静态成员类，匿名类，局部类

3.非静态成员类每个实例都隐含着与外围类的一个实例相关联。

4.如果嵌套类的实例可以在它的外围类的实例之外独立存在，这个嵌套类就必须是静态成员类；在没有外围实例的情况下，想创建非静态成员类的实例是不可能的。

5.非静态成员类的一种常见用法是定义一个Adapter，它允许外部类的实例被看作是另一个不相关的类的实例。（如集合视图 keySet iterator）

6.如果声明成员类不要求访问外围实例，那成员类就应该是静态的。非静态成员类的实例必须要有一个外围的实例

7.私有静态成员类的一种常见用法是用来代表外围类所代表的对象的组件。

8.匿名类的常见用法是①动态地创建函数对象（第21条），②创建对象过程（Runabel,Thead,TimerTask）,③在静态工厂方法的内部

9.在任何可以声明局部变量的地方，都可以声明局部类，并且局部类也遵守同样的作用域规则。

`四` 泛型

`23`.不要在新代码中使用原生态类型

1.错误应该尽早发现，最好在编译期就发现。

2.如果使用原生类型，就失去了泛型在安全性和表述性方面的所有优势

3.在不在乎集合中的元素类型时，使用无限制的通配符类型（<?>）

4.在类文字中必须使用原生态类型；因为泛型会被擦除，所以instanceof操作符使用原生类型就可以了。

`24`.消除非受检警告

1.泛型相关的编译警告：

非受检强制转化警告（unchecked cast warnnings）

非受检方法调用警告

非受检普通数组创建警告

非受检转换警告（unchecked conversion warnings）

2.要尽可能地消除每一个非受检警告

3.如果无法消除警告，可以同时证明引起警告的代码是类型安全的，只有在这种情况下才可以用一个@SuppressWarnings("unchecked")注解来禁止这条警告。

4.SuppressWarnings注解可以用在任何粒度的级别中，应该始终在尽可能小的范围中使用它，永远不要在整个类中使用它

5.如果在长度不止一行（即一行代码中存在多个动作）的代码中使用了SuppressWarnings注解，可以将它移到一个局部变量声明中，以减小SuppressWarnings注解的影响范围。

6.每当使用@SuppressWarnings("unchecked")时，都要添加一条注释，说明为什么这么做是安全的。

`25`.列表优先于数组

1.数组与泛型的区别

数组是协变的，如果sub为super的子类型，那么sub[]也是super[]的子类型；相反，泛型则是不可变的，对于两个类型Type1与Type2，List<Type1>与List<Type2>没有任何关系。

数组是具体化的，因此数组在运行时才知道并检查它的元素类型约束；而泛型则是通过擦除（erasure）来实现的，泛型只在编译时强化类型信息，并在运行时擦除元素类型信息，擦除可以使泛型与早期无泛型的代码兼容。

2.泛型与数组不能混合使用，因为泛型数组不是类型安全的。（因为数组是协变的，所以数组可以自动向上转型，我们可以往向上转型后的数组中插入与转型前不同的类型的数据，而借转型前数组名义取出的对象将会产生CalssCastException）

List<String>[] stringLists = new List<String>[];
List<Integer> intList = Arrays.asList(42);
Object[] objects = stringLists;
objects[0] = intList;
String s = stringLists[0].get(0);

3.每当调用可变参数方法时，就会创建一个数组来存放参数，如果这个数组的元素类型不是可具体化的，就会得到一条警告，除了禁止这个警告，别无他法。

4.数组提供了运行时的类型安全，但是没有提供编译时的类型安全；泛型提供了编译时的类型安全，但是没有提供运行时的类型安全。

5.不可具体化的类型数组转换只能在特殊情况下使用。

`26`.优先考虑泛型

1.禁止数组类型的未受检转换比禁止标量类型的更加危险

2.使用泛型比使用需要在客户端代码中进行转换的类型更加安全，也更加容易，在设计新类型的时候，要确保不需要这种转换就能使用。

`27`.优先考虑泛型方法

1.如果泛型方法返回的对象是无状态的，可以考虑将该对象做成泛型单例

2.调用泛型方法时，编译器会对返回值进行类型推到，以适应接收者的类型

`28`.利用有限通配符来提升API的灵活性

1.泛型中使用extends时，每个类型都是自身的子类型；使用super时，每个类型都是自身的超类型。

2.为了获得最大限度的灵活性，要在表示生产者或者消费者的输入参数上使用通配符类型。PECS（producer-extends；consumer-super）

3.不要用通配符类型作为返回类型

4.如果编译器不能推断你希望它拥有的类型，可以通过显式的类型参数来指定。

5.如果类型参数在方法中声明中只出现一次，可以用通配符取代它。

6.不能把null之外的任何值放进List<?>中

`29`.优先考虑类型安全的异构容器

1.cast方法是java的cast操作符的动态模拟，它只检验它的参数是否为Class对象所表示的类型的实例，如果是，就返回参数，否则抛出ClassCastException

2.类型安全的异构容器的缺陷

恶意的客户端可以很轻松的破坏类型安全，只要它以原生态类型使用Class对象，在容器的添加方法第一行加入参数的类型检查（type.cast(obj)）可以避免这种问题。

不可存放不可具体化的类型数据（如List<String>，因为List<String>的类型为List.class，而List<String>.class是语法错误），只能保存String或String[]等可具体化的对象。

3.利用有限制类型参数或者有限制通配符来限制可以表示的类型

4.asSubclass(List.class)方法将Class类的类型令牌安全且动态地转换成参数所表示的类(List)的一个子类的通配符表示法(? extends List)，参数必须为调用者的父类型，如果成功，返回它的参数，否则抛出ClassCastExcpetion

`五` 枚举和注解

`30`.用enum代替int常量

1.因为没有可以访问的构造器，枚举类型是真正的final。

2.枚举类型允许添加任意的方法和域，并实现任意的接口。枚举提供了所有Object方法的高级实现，实现了Comparable和Serializable接口，并针对枚举类型的可任意改变性设计了序列化方式。

3.枚举有一个静态的values方法，按照声明顺序返回它的值数组，toString方法返回每个枚举值的声明名称。

4.在同一个枚举类型中，将特定的行为与每个具体的枚举常量关联起来：在枚举类型中声明一个抽象的方法，并在特定于常量的类主体中，覆盖该方法。

5.每一个枚举常量可以关联特定的数据（在构造器中绑定），因此特定于枚举常量的方法可以与特定于枚举常量的数据结合起来。

6.枚举类型有一个自动产生的valueOf(string)方法，它将常量的名字转变成常量本身。如果枚举类型中覆盖toString，要考虑编写一个fromString方法，将定制的字符串表示法变回相应的枚举。

7.如果多个枚举常量同时共享多个行为，要考虑策略枚举。

`31`.用实例域代替序数

1.所有枚举都有一个ordinal方法，它返回每个枚举常量在类型中的数字位置

2.永远不要根据枚举的序数导出与他关联的值，而是要将值保存在一个实例域中。

`32`.用EnumSet代替位域

1.or位运算将几个常量合并到一个集合中，称为位域。（形如111→rwx）

2.EnumSet可以表示从单个枚举类型中提取的多个值的集合，EnumSet.of

3.截止jdk1.6，无法创建不可变的EnumSet

`33`.用EnumMap代替序数索引

1.EnumMap构造器采用键类型的Class对象：这是一个有限制的类型令牌，它提供了运行时的泛型信息。实例化需要指定Class类型，可以保存同一个类型的对象与值的映射关系

2.最好不要用序数来索引数组，而要用EnumMap，如果需要表示的关系是多维的，就用嵌套的EnumMap

`34`.用接口模拟可伸缩的枚举

1.用接口模拟可伸缩的枚举有个小小的不足，即无法实现从一个枚举类型继承到另一个枚举类型。

2.虽然无法编写可扩展的枚举类型，却可以通过编写接口以及实现该接口的基础枚举类型，模拟可伸缩的枚举。<T extends Enum<T> & interfaceType>

`35`.注解优先于命名模式

1.注解的声明类型就是自身通过Retention和Target 注解进行注解，@Retention(RetentionPolicy.RUNTIME)元注解表明，应该在运行时保留；@Target(ElementType.METHOD)元注解表明，只有在方法声明中才是合法的。

2.InvocationTargetException 封装了目标方法在运行时产生的异常，出现该异常表明目标方法确实被运行了，使用getCause()可以获得方法运行时产生的具体异常。

3.用花括号包裹用逗号分隔的参数将自动变成参数数组

4.如果编写的工具需要在源文件上添加信息，就要定义一组适当的注解类型。

`36`.坚持使用Override注解

1.Override会对标记的方法进行代码检查，确保该方法成功地被重写了。

2.现代IDE在检测到Override注解时会提醒用户小心无意识的覆盖。

3.在抽象类或接口中使用Override可以确保不会添加新的方法。

`37`.用标记接口定义类型

1.标记接口是没有包含方法声明的接口，只是指明了实现类应该具有的属性。

2.标记接口有两点胜过注解

标记接口可以在编译时进行类型检查，保证参数的有效性

标记接口类型更容易指定实现类的约束条件，如Set就是一个标记接口，他限制了实现类必须具有Collection特性。

3.注解有两点胜过标记接口

注解可以在内部丰富信息而不影响客户端使用

标记注解在支持注解的框架中具有一致性

4.如果标记需要应用到任何程序元素而不仅仅是类或接口上，就应该使用注解；否则应该使用标记接口；如果该标记只用于特定的接口，最好将标记定义成该接口的子接口(Set与Collection)

5.如果一个标记永远不会扩展，应该定义成标记接口；如果未来可能需要在标记上添加更多信息，则应该定义成标记注解。

`六` 方法

`38`.检查参数的有效性

1.应该在发生错误后，能够尽快检测出错误，不要让错误在过深的地方爆发出来。

2.对于公有的方法，要用@throws标签在文档中说明违反参数值限制时会抛出的异常。

3.非公有的方法通常应该使用断言来检查参数， -ea启用

4.如果有效性检查非常昂贵，或者已经隐含在计算中完成则无需进行检查

5.使用异常转译技术，将计算过程中抛出的异常转换为正确的异常。

`39`.必要时进行保护性拷贝

1.对构造器的每个可变参数进行保护性拷贝

2.保护性拷贝是在检查参数的有效性之前进行的，并且有效性检查是针对拷贝之后的对象，而不是针对原始对象，这样可以避免在拷贝阶段从另一个线程改变类的参数。

3.对于参数类型可以被不信任方子类化的参数，不要使用clone。

4.如果需要访问类的内部域，返回内部域的保护性拷贝。

5.如果不能容忍客户端传入的对象可变，使用保护性拷贝

6.长度非0的数组总是可变的，使用保护性拷贝或者返回数组的不可变视图

7.通常使用Date.getTime()返回的long类型作为内部的时间表示法。

8.包装类一般客户端自己使用，无需使用保护性拷贝。

`40`.谨慎设计方法签名

1.谨慎地选择方法的名称

2.不要过于追求提供便利的方法，只用某项操作被经常用到时，才提供快捷方式。

3.避免过长的参数列表，相同类型的长参数序列格外有害。

缩短参数列表的三种方法

把方法分解成多个方法，但是会导致方法过多，但是提升方法的正交性，可以减少方法数目。

创建辅助类，用来保存参数的分组。

从对象构建到方法调用都采用Builder模式

4.对于参数类型，优先使用接口而不是类。

5.对于boolean参数，要优先使用连个元素的枚举类型。

`41`.慎用重载

1.要调用哪个重载方法是在编译时做出决定的。

2.对于重载方法的选择是静态的，而对于被覆盖的方法的选择是动态的。

3.如果普通用户根本不知道”对于一组给定的参数，其中哪个重载方法将会调用”，那么这样的API很可能导致错误。

4.安全而保守的策略是，永远不要导出两个具有相同参数数目的重载方法；如果方法使用可变参数，保守的策略是根本不重载它。

5.一个类的多个构造器总是重载的，很多情况下可以用静态工厂代替构造器。

6.对于一对重载方法，如果至少有一个对应的参数在两个方法中具有”根本不同（无法强转）”的类型，那就不会让用户感到混淆。

7.将list.remove()参数转换成Integer，迫使选择正确的重载方法。java语言添加了自动装箱后，破坏了List接口。

8.当传递的参数没有本质的不同时，必须确保所有的重载方法行为一致，做法是让更具体化的重载方法把调用转发给更一般化的重载方法。

`42`.慎用可变参数

1.参数数量检测无法在编译期完成

2.可变参数方法会将多个参数收集成数组，但若参数本身就是数组，那么收集后的数组将无法得到预期的结果（Arrays.asList）

3.不必改造具有数组参数的每个方法；只当确实是在数量不定的值上执行调用时才使用可变参数

4.重视性能时要小心，可变参数方法每次调用都会进行数组分配和初始化

5.提供大多数使用情况下的不可变参数方法，再额外附加可变参数方法（EnumSet.of）

`43`.返回零长度的数组或者集合，而不是null

1.如果返回null，每次调用该方法时都会需要进行空值判断

2.长度为0的数组是不可变的，因此返回的空数组可以自由共享

（Collections.emptySet；

Collections.emptyList；

Collections.emptyMap）

`44`.为所有导出的API元素编写文档注释

1.文档注释应该简洁地描述出它和客户端之间的约定

2.应该列举出这个方法的所有前提条件，后置条件和副作用

3.{@code}会造成包裹的内容以代码片段形式呈现（即生成code标签）

4.{@literal}会自动转义包裹的内容

5.同一个类或者接口中的两个成员或者构造器，不应该具有相同的概要描述

6.不要忽视类是否是线程安全的，以及类是否是可序列化的。

7.{@inheritDoc}继承注释

`七` 通用程序设计

`45`.将局部变量的作用域最小化

1.最有力的方法就是在第一次使用它的地方声明

2.几乎每个局部变量都应该包含一个初始化表达式，如果没有足够的信息来进行有意义的初始化，就推迟这个声明，try-catch除外。

3.循环中提供了特殊的机会来将变量的作用域最小化，如果在循环终止后不再需要循环变量的内容，for循环就优先于while循环。

`46`.for-each 循环优先于传统for循环

1.嵌套的for-each循环，外层循环的对象可以在内层对象中保持，不会随内层循环移动指针。

2.有3种情况无法使用for-each

需要遍历并删除元素时

需要遍历元素并取代某些值时

需要并行迭代多个集合时

`47`.了解和使用类库

java.lang；

java.util；

java.io；

java.util.concurrent；

`48`.如果需要精确的答案，请避免使用float和double

使用BigDecimal，int 或者 long 进行货币计算

`49`.基本类型优先于装箱基本类型

1.基本类型与装箱基本类型的区别

基本类型只有值，而装箱基本类型的同一性不仅取决于值

装箱基本类型除了值还多了一个null

基本类型更节省空间

2.对装箱基本类型使用==操作符几乎总是错误的。

3.当一项操作中混合使用基本类型和装箱基本类型时，装箱基本类型会自动拆箱。若被拆的对象为null，将抛出异常。

4.在集合中只能使用装箱基本类型

`50`.如果其他类型更适合，则尽量避免使用字符串

1.字符串不适合代替其他的值类型

2.字符串不适合代替枚举类型

3.字符串不适合代替聚集类型（即将多个部分拼接成字符串用关键字分隔），最好用一个简单的类来代替。

4.字符串不可替代控制共享资源访问权限的键

`51`.当心字符串连接的性能

1.为连接n个字符串而重复地使用字符串连接操作符，需要n的平方级的时间

2.为了性能，用StringBuilder替代String

`52`.通过接口引用对象

1.如果有合适的接口类型存在，那么对于参数，返回值，变量和域来说，就都应该使用接口类型进行声明

2.如果对象属于基于类的框架，就应该使用基类引用这个对象，尽量用抽象类型引用对象

3.如果程序依赖于类中额外的方法，那么这种类应该只被用来引用实例，而不应该作为参数类型。

`53`.接口优先于反射机制

反射功能应该只有在设计时被用到，或者只是用来创建对象，程序在运行时不应该以反射方式访问对象

`54`.谨慎地使用本地方法

1.本地方法3个用途

提供访问特定于平台的机制的能力，如注册表和文件锁

提供了访问遗留代码库的能力

通过本地语言，编写程序中注重性能的部分

2.使用本地方法不值得提倡，java.util.prefs提供了访问注册表的能力，java.awt.SystemTray提供了访问桌面系统托盘的能力

3.本地语言是不安全的，无法免受内存毁坏错误的影响。

`55`.谨慎地进行优化

1.好的程序体现了信息隐藏的原则，只要有可能，就要把设计决策（暂时理解为业务逻辑）集中在单个模块中，因此，可以改变单个决策，而不会影响到系统的其他部分。

2.努力避免那些限制性能的设计决策，系统中最难更改的是指定模块交互关系的组件，API，线路层协议和永久数据格式

3.要考虑API设计设计决策的性能后果

如果将公类类型成为可变的，就可能导致大量不必要的保护性拷贝

在适合使用复合模式的公有类中使用继承，会把这个类与它的超类永远束缚在一起

在API中使用实现类而不是接口，会将客户端束缚在具体的实现类上，如果将来出现更快的实现也无法使用。

`56`.遵守普遍接受的命名习惯

1.《The Java Language Specification》

2.对于缩写单词，也应该遵守首字母大写原则

3.常量域是唯一推荐使用下划线的情形

4.类型参数，T任意类型，E集合元素类型，KV键值映射类型，X异常，任何类型的序列可以是T,U,V或者T1,T2,t3

5.转换对象类型，返回不同类型的独立对象的方法 toType；

返回视图asType；

返回一个与被调用对象相同值的基本类型的方法typeValue；

静态工厂valueOf，of，getInstance，

newInstance，getType，NewType

`八` 异常

`57`.只针对不正常情况使用异常

1.异常机制的设计初衷是为了不正常的情形，很少有JVM实现会对它进行优化；把代码放在try-catch中反而阻止了本来可以进行的优化；对数组进行遍历的标准模式并会不导致冗余的检查，有些现代的JVM实现会将它们优化掉。

2.异常只应用于不正常情况，不应该用于正常的控制流。

3.如果类具有状态，有两种方法可以避免异常，第一种是状态测试法，如Iteable接口的hasNext。

4.另一种方法是可识别返回值法，并发环境下或状态检查影响性能时更适用，如果所有情况等同，优先使用状态检测法。

`58`.对可恢复的情况使用受检异常，对编程错误使用运行时异常

1.三种可抛出结构：受检异常，运行时异常，错误

2.如果期望调用者能够适当地恢复，使用受检的异常

3.用运行时异常表明编程错误，大多数运行时异常表示提前违例，即API用户没有遵守约定

4.错误通常被JVM保留，用于表示资源不足，约束失败等，最好不要再实现任何新的Error子类

5.如果不清楚是否有可能恢复，最好使用未受检的异常

6.受检的异常往往需要表明可回复条件，提供一些便于查询信息的方法尤其重要

`59`.避免不必要地使用受检的异常

1.如果正确使用API不能阻止异常的产生，而一旦产生异常API使用者能够立即采取有效的动作，就值得使用受检的异常，除非两个条件都成立，否则更适合使用未受检异常。

2.把受检的异常变成未受检异常的方法是把抛出异常的方法分成两个方法，其中一个方法返回boolean表示是否应该抛出异常（类似状态检测法）。这种方法在并发环境下或者异常检测很耗性能时则不适用。

`60`.优先使用标准的异常

ConcurrentModificationException；

UnsupportedOperationException

`61`.抛出与抽象相对应的异常

1.更高层的实现应该捕获低层的异常，同时抛出可以按照高层抽象进行解释的异常，这种做法称为异常转译

2.一种特殊的异常转译形式称为异常链，如果低层异常对于调试高层异常有帮助，就适合使用异常链，高层异常提供访问方法获得低层异常（Throwable.getCause）

3.大多数标准异常都有异常链构造器，没有异常链构造器的，可以使用Throwable的initCause方法设置原因。

4.异常转译不应滥用，更好的做法是及时进行参数检查，尽早中断异常链。

`62`.每个方法抛出的异常都要有文档

1.始终要单独声明受检的异常，而不是抛出多个异常的共同的超类，并且利用@throws标记，准确记录下抛出每个异常的条件

2.不要在方法声明中抛出任何RuntimException

3.如果一个类中的多个方法出于同样的原因抛出同样的异常，可以将异常的信息写入到类的文档注释中。

`63`.在细节消息中包含能捕捉失败的信息

1.如果捕获失败，异常的细节信息应该包含所有对异常有贡献的参数和域的值

2.在异常的构造器中引入细节信息

`64`.努力使失败保持原子性

1.失败的方法调用应该使对象保持在被调用之前的状态

2.保持失败原子性的方法：

设计不可变类

检查参数有效性，提前失败，将所有可能产生失败的运算放到改变状态的操作之前

编写恢复代码

在对象的一份临时拷贝上操作，然后用拷贝中的结果代替对象的内容（如Collections.sort）

3.在缺乏同步机制的情况下并发访问对象，难以保持失败原子性。

`65`.不要忽略异常

有一种情形可以忽略异常，即关闭FileInputStream时，因为文件状态没有改变，不必终止当前操作，即使这种情况下，也应该将异常信息记录下来，以便排查。

`九` 并发

`66`.同步访问共享的可变数据

1.同步可以保证每个线程看到的对象处于一致的状态中；保证每个线程都看到锁对象被修改的结果。

2.java语言规范保证，读或者写一个变量是原子的，除非这个变量的类型为long或double

3.读写原子数据的时候也应该使用同步，不仅为了互斥访问，也为了在线程间进行可靠的通信。详见java内存模型。

4.不要用Thead.sotp。要中断一个线程，建议做法是轮询boolean域，通过另一个线程修改这个boolean域；具体方法是添加对这个boolean域的读写方法，并对读写方法添加同步。

5.volatile修饰符虽然不执行互斥访问，但是可以保证每个线程在读取该域的时候都能看到最近刚被写入的值。

6.使用AtomicLong进行原子化long操作

7.最佳做法是要么不共享可变数据，要么就共享不可变数据，就是将可变数据限制在单个线程内部。

8.活性失败：线程永远无法读取到变量的变化

9.安全性失败：一个线程修改非原子变量时，另一个线程过来读取，此时只能读取到过渡状态的数据。

`67`.避免过度同步

1.为了避免活性失败和安全性失败，在一个被同步的方法或者代码块中，永远不要放弃对客户端的控制。尽量不要在同步代码块中调用可被覆盖的方法或者客户端提供的方法（原则上永远不要信任客户端）

2.当客户端造成服务端变化后能够预定通知，即观察者（Observer）模式

3.线程B需要获得锁才能继续执行，但是线程B执行完当前的代码片段后，线程A才能让出锁，此时将会造成死锁。死锁的根本原因是，多个线程同时需求同步锁。

4.java中的锁是可重入的，这样的锁简化了多线程面向对象的构造

5.不要把锁对象传递给客户端，而是传递锁对象的快照，这样可以避免死锁

6.java类库提供了并发集合CopyOnWriteArrayList

7.同步区域内的工作越少越好

8.如果一个可变的类需要并发访问，应该使这个类变成线程安全的，通过内部同步可以实现；如果不确定是否需要同步，那就不要同步，并建立文档，注明它不是线程安全的

9.如果在内部同步了类，就可以进行分拆锁，分离锁和非阻塞并发控制

10.如果方法修改了静态域，那么就必须同步对这个域的访问，即使它往往只作用于单个线程，这是为了可靠的线程通信

`68`.executor和task优先于线程

1.Executor Framework

ExecutorService executor = Executors.newSingleThreadExecutor();
executor.execute(runnable);
executor.shutdown();
invokeAny
invokeAll
awaitTermination
ExecutorCompletionService

2.如果编写的是小程序，或者轻载服务器，使用Executors.newCachedThreadPool

3.在大负载的产品服务器中，使用Executors.newFixedThreadPool

4.尽量不要编写自己的工作队列，尽量不直接使用线程。现在的关键抽象不再是Thread了，而是task。task有两种：Runnable与Callable，执行任务的关键机制是ExecutorService。

5.ScheduledThreadPool代替Timer

6.《Java Concurrency in Practice》

`69`.并发工具优先于wait和notify

1.concurrent包中三类工具：

Executor Framework

并发集合

同步器

2.并发集合中不可能排除并发活动，将他锁定没什么作用，只会使程序速度变慢。

3.应该优先使用ConcurrentHashMap，而不是Collections.synchronizedMap或者Hashtable

4.阻塞队列用于工作队列或生产者-消费者队列，任意个生产者线程向工作队列中添加项目，并且当工作项目可用时，任意个消费者线程从工作队列中取出项目

5.同步器是一些使线程能够等待另一个线程的对象（互斥），最常用的同步器是CountDownLatch和Semaphore，较不常用的是CyclicBarrier和Exchanger

6.倒计数锁存器，当countDown数量足够时，将自动从await状态唤醒，否则将继续等待。

7.线程饥饿死锁

8.对于间歇式的定时，始终应该优先使用System.nanoTime，而不是System.currentTimeMills

9.a.wait()，使所有访问a对象的线程等待，该方法必须在同步区域内被调用；始终应该使用wait循环模式调用wati方法，永远不要在循环之外调用wait方法。

10.优先使用notifyAll，因为被意外唤醒的线程会在循环中检查条件，如果条件不满足，会继续等待。

`70`.线程安全性的文档化

1.在一个方法声明中出现synchronized修饰符，这个是实现细节，不是导出API的一部分

2.一个类为了可以被多个线程安全地使用，必须在文档中清楚说明它所支持的线程安全级别：

不可变的

无条件的线程安全：可变类，但是有足够的内部同步，可以被并发使用

有条件的线程安全：某些方法需要外部同步

非线程安全：必须外部同步

线程对立：即使所有调用都有外部同步，依旧不能安全地并发使用。通常因为没有同步地修改静态数据

3.必须指明哪个调用序列需要外部同步，还要指明为了调用这个序列，必须获得哪一把锁。如果一个对象代表了另一个对象的一个视图，客户端通常就必须在后台对象上同步，以防止其他线程直接修改后台对象。

4.除非从返回类型来看已非常明显，否则静态工厂必须在文档中说明被返回对象的线程安全性

5.私有锁对象必须声明为final的，只能用在无条件线程安全类上，有条件线程安全类不能使用，因为外部调用时无法获得锁。

`71`.慎用延迟初始化

1.对静态域使用延迟初始化，用 lazy initialization holder class 模式（静态私有内部类）

2.对实例域使用延迟初始化，用双重检查模式，第二次检查在同步中进行

3.如果允许重复初始化，用单重检查模式

`72`.不要依赖于线程调度器

1.任何依赖于线程调度器来达到正确性或者性能要求的程序，很可能不可移植

2.最好的办法是确保可运行的线程平均数量不明显多于处理器数量

3.如果线程没有在做有意义的工作，就不应该运行

4.不要企图通过Thread.yield来修正程序，它唯一的作用是在测试期间人为增加程序的并发性

5.线程优先级是Java平台上最不可移植的特征

`73`.避免使用线程组

`十` 序列化

`74`.谨慎地实现Serializable接口

1.实现Serializable接口的代价是，

一旦一个类被发布，就大大降低了改变这个类实现的可能性
增加了出现BUG和安全漏洞的可能性，反序列化是语言之外的对象创建机制
随着类发行新的版本，相关的测试负担也增加了

2.如果没有声明serialVersionUID，系统将在运行时通过类名，接口，成员等自动产生

3.为了继承而设计的类，应该尽少实现Serializable接口，用户接口也应该尽少继承Serializable接口

4.如果类有一些约束条件，当类的实例域被初始化为默认值，就会违背这些约束条件，此时需要添加readObjectNoData方法，并在其中抛出InvalidObjectException

5.对于为继承而设计的可序列化的类，应该提供一个无参构造器，以及一个初始化方法，readObject与有参构造器共用这个初始化方法

6.AtomicReference操作原子引用，这是一个很好的线程安全状态机

7.内部类不应该实现Serializable，内部类的默认序列化形式是定义不清楚的，然而静态成员类却可以实现Serializable

`75`.考虑使用自定义的序列化形式

1.如果没有先认真考虑默认的序列化形式是否合适，则不要贸然接受；理想的序列化形式应该只包含该对象所表示的逻辑数据，而逻辑数据与物理表示法应该是各自独立的

2.如果一个对象的物理表示法等同于它的逻辑内容，可能就适合于使用默认的序列化形式

3.即使确认了默认的序列化形式是合适的，通常还必须提供一个readObject方法以保证约束关系和安全性

4.当一个对象的物理表示法与逻辑内容有实质性的区别时，使用默认的序列化形式会有以下4个缺点

这个类的导出API永远束缚在该类的内部表示法上
消耗过多的空间，因为会反序列化所有的域
消耗过多的时间，因为会遍历对象图的拓扑关系
引起栈溢出，因为会递归遍历对象图

5.defaultWriteObject方法被调用的时，每个未被标记为transient的域都会被序列化；defaultReadObject将会反序列化这些域，在决定将一个域做成非transient之前，一定要确信它的值将是逻辑状态的一部人

6.如果所有的域都是瞬时的，不调用defaultWriteObject和defaultReadObject也是允许的，但是不推荐这么做，可能会引起StreamCorruptedException

7.如果在读取整个对象状态的任何其他方法上强制任何同步，则也必须在对象序列化上强制这种同步

8.不管选择哪种序列化形式，都要为自己编写的每个可序列化的类声明一个显式的序列版本UID，这样可以避免因为自动生成UID造成不兼容

9.如果想为一个类生成一个新的版本，使这个类与现有的类不兼容，那么只需修改UID即可，反序列化时将会发生InvalidClassException

`76`.保护性地编写readObject方法

1.《Java Object Serialization Specification》

2.当一个对象被反序列化的时候，如果哪个域将被客户端所引用，就必须要做保护性拷贝

3.不要使用writeUnshared和readUnshared方法

writeUnshared：将“未共享”对象写入 ObjectOutputStream。此方法等同于 writeObject，不同点在于它总是将给定对象作为流中惟一的新对象进行写入

readUnshared：从流中读取一个不共享的对象，同readObject，但不会让后续的readObject和readUnshared调用引用这次调用反序列化得到的对象

4.readObject不可以调用可被覆盖的方法，一旦调用，这个方法将在子类的域被反序列化之前运行，如果这个方法依赖子类的域，将导致程序失败

5.对于任何约束条件，如果检查失败，则抛出InvalidObjectException，这写检查应该在所有的保护性拷贝之后

6.如果整个对象图在反序列化之后必须进行验证，则使用ObjectInputValidation接口

`77`.对于实例的控制，枚举类型优先于readResolve

1.在反序列化之后，新建对象上的readResolve方法将被调用，然后该方法返回的对象将取代新建的对象

2.如果依赖readObject进行实例控制，带有对象类型的所有实例域必须声明为transient的

3.用readResolve进行实例控制并不过时，如果必须编写可序列化的实例受控的类，它的实例在编译时还不知道，你就无法将类表示成枚举

4.如果把readResolve放在一个final类上，它就应该是私有的；如果readResolve方法不是私有的，并且子类没有覆盖它，对序列化过的子类进行反序列化，将会获得一个超类的实例，可能出现ClassCastException

`78`.考虑用序列化代理代替序列化实例

1.实际在流之间传输的是代理对象，反序列化之后，代理对象通过readResolve返回对象，此时通过构造器创建外围对象，构造器中自带参数检查；序列化时，外围类通过writeReplace返回序列化代理实例。

2.writeReplace方法将在对象被写入流之前执行，然后用方法返回的实例替换自身被写入流中，与readResolve相对