意图

Proxy是结构模式的一种，它能够让你为另外一个对象提供一个替身或者占位符来控制对它的访问。

问题

为什么要控制对对象的访问？比如：你有一个需要消耗大量系统资源的对象。你时不时会用到它，但不是一直使用。

因此，这个对象不用再程序启动时创建，而是当真正需要它的时候再创建。每个用到这个对象的客户端可能都有一些延迟实例化代码。显而易见，它导致了大量重复代码。

理想状态下，我们可以直接在对象类中加入代码，但不总是这样。比如，这是第三方库中的类。

目的

Facade是结构模式的一种，它让你可以为一个复杂的系统，类库或者框架提供一个简单的接口。

问题

想象一下，代码必须和一大堆复杂的框架或者类库协作。你必须手动实力话这些对象，跟踪依赖，正确的顺序关系等等。

最后，你的业务逻辑类会和第三方类库的实现紧密耦合。这些代码难以理解和维护。

目的

Composite是结构设计模式的一种，允许你像树一样组合对象，并且允许客户端像单个对象一样和这些结构协作。

问题

Composite模式只有在你的业务模型可以被表示为一个树结构时才有意义。

比如，你有两个对象：Product和Box。这个Box可以包含几个Product和一些更小的Box。这些更小的Box也可以包含一些Product或者更小的Box等等。

现在，想象你的Product和Box是订单的一部分。计算订单的总价会非常困难。你拿到了一个大的Box，打开后看到它里面还有：ProductA，ProductB或者其他的Box，让我们再看看它里面有什么…不久，你将会停在一堆胶带和纸盒上，但仍在尝试计算总价。

那么，有更好的方法吗？

目的

Bridge是结构模式的一种，它可以帮你分离一个巨大的类或者将一组关系相近的类分离成为两个独立的层次结构，抽象和实现，可以各自独立开发。

问题

抽象？实现？听起来害怕？我们首先来看个简单的例子。

你有一个几何Shap类，他有一对子类：Square和Triangle。你希望扩展这个层次结构来融入颜色以便创建红色和蓝色的形状。但是因为你已经有子类，你需要创建4个类来组合，比如BlueSquare和RedTriangle。

目的

Decorator（装饰器）是一个结构设计模式，可以让你在封装包涵对象原有行为的基础上增加新的行为。

问题

你需要动态的添加或者移除一个对象的责任，但是你要做到和应用中其他代码的兼容。

当你需要扩展一个类的行为时继承时第一个想到的处理方式。然而，继承是静态的。你不能够增加一个新的类到程序中当它已经编译或者执行完成。

目的

适配器是一种结构设计模式，使得不兼容接口间的可正常进行协作。

问题

想象你有一个使用XML作为数据处理格式的APP，但你用到了一个仅支持JSON数据格式的类库。

举个例子，你有一个做股票数据的APP。他从多个数据源获取XML来展示成图标。在一个新版本中，你决定使用一些三方的分析包。但是有一个问题：分析包仅支持JSON数据。

在这种情况下，可以重写你自己的代码以便支持JSON或者改变依赖的库使其支持XML。第一种选择要破坏已有的代码，第二种选择看上去是不可能的，因为我们常常无法修改三方库。

引入

之前写过一篇关于Spring代理流程的博客，当时没有深入思考，最近碰到一个有趣的事情，类内部调用带有spring注解，但注解不生效的问题，举例说明：

1
2
3
4
5
6
7
8
9
10
11
12

public class SimplePojo implements Pojo {

    public void foo() {
        // this next method invocation is a direct call on the 'this' reference
        this.bar();
    }

	@Transaction
    public void bar() {
        // some logic...
    }
}

初识ClassLoader

1. 在开发中有时会碰到ClassNotFoundException。这个异常和ClassLoader有着密切的关系。

2. 我们常使用instanceof关键字判断某个对象是否属于指定Class创建的对象实例。如果对象和Class不属同一个加载器加载，那么instanceof返回的结果一定是false。

3. GC Root有一种叫做System Class，官方解释“Class loaded by bootstrap/system class loader. For example, everything from the rt.jar like java.util. .”，大意是：被bootstrap/system加载器加载的类，比如，像java.util.这些来自rt.jar的类。

4. GC时对Class的卸载，需要满足的条件如下：

类需要满足以下3个条件才能算是“无用的类”

• 该类所有的实例已经被回收
• 加载该类的ClassLoder已经被回收
• 该类对应的java.lang.Class对象没有任何对方被引用
  阅读全文 »

第22章 异步请求

Servlet3.0规范新增了对异步请求的支持，Spring MVC也在此基础上对异步请求提供了方便。异步请求是在处理比较耗时的业务时先将request返回，然后另起线程处理耗时的业务，处理完后再返回给用户。

异步请求可以给我们带来很多方便，最直接的用法就是处理耗时的业务，比如，需要查询数据库、需要调用别的服务器来处理等情况下可以先将请求返回给客户端，然后启用新线程处理耗时业务，等处理完成后再将结果返回给用户。稍微扩展一下还可以实现订阅者模式的消息订阅功能，比如，当有异常情况发生时可以主动将相关信息发给运维人员，还有现在很多邮箱系统中收到新邮件的自动提示功能也是这种技术。甚至更进一步的使用方式是在浏览器上做即时通信的程序！

最近线上JDK升级到啦1.8，应用在发布时，总会发生Full GC报警，看了下GC日志，发现应用重启时会接连发生4次Full GC，但是这4次GC后很久一段时间（第二天再次查看GC日志和jstat的统计）没有再发生Full GC，查了下官方资料，顺便翻译出来，方便以后阅读。翻译的不好，请见谅，也欢迎提出建议，在下将不胜感激。

原文链接：https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html

The Concurrent Mark Sweep (CMS) collector is designed for applications that prefer shorter garbage collection pauses and that can afford to share processor resources with the garbage collector while the application is running. Typically applications that have a relatively large set of long-lived data (a large tenured generation) and run on machines with two or more processors tend to benefit from the use of this collector. However, this collector should be considered for any application with a low pause time requirement. The CMS collector is enabled with the command-line option -XX:+UseConcMarkSweepGC.

CMS收集器特点：1.更短的垃圾回收暂停(stop the world) 2.垃圾收集器能够在应用运行时与其共享处理器资源。通常，一个运行在多处理器机器上并且其中有长期存活的大集合(较大的老生代)的应用可以考虑使用CMS收集器。当然，对于具有低暂停时间要求的应用，都可以考虑使用该收集器。使用-XX:+UseConcMarkSweepGC来启用CMS收集器。