Shiro 快速入门

Shiro 是一个安全框架，具有认证、授权、加密、会话管理功能。

一、Shiro 简介

Shiro 特性

核心功能：

• Authentication - 认证。验证用户是不是拥有相应的身份。
• Authorization - 授权。验证某个已认证的用户是否拥有某个权限；即判断用户是否能做事情，常见的如：验证某个用户是否拥有某个角色。或者细粒度的验证某个用户对某个资源是否具有某个权限。
• Session Manager - 会话管理。即用户登录后就是一次会话，在没有退出之前，它的所有信息都在会话中。会话可以是普通 JavaSE 环境的，也可以是如 Web 环境的。
• Cryptography - 加密。保护数据的安全性，如密码加密存储到数据库，而不是明文存储。

辅助功能：

• Web Support - Web 支持。可以非常容易的集成到 Web 环境；
• Caching - 缓存。比如用户登录后，其用户信息、拥有的角色 / 权限不必每次去查，这样可以提高效率；
• Concurrency - 并发。Shiro 支持多线程应用的并发验证，即如在一个线程中开启另一个线程，能把权限自动传播过去；
• Testing - 测试。提供测试支持；
• Run As - 运行方式。允许一个用户假装为另一个用户（如果他们允许）的身份进行访问；
• Remember Me - 记住我。即一次登录后，下次再访问免登录。

:bell: 注意：Shiro 不会去维护用户、维护权限；这些需要我们自己去提供；然后通过相应的接口注入给 Shiro 即可。

Shiro 架构概述

• Subject - 主题。它代表当前用户，Subject 可以是一个人，但也可以是第三方服务、守护进程帐户、时钟守护任务或者其它——当前和软件交互的任何事件。Subject 是 Shiro 的入口。

  • Principals 是 Subject 的“识别属性”。Principals 可以是任何可以识别 Subject 的东西，例如名字（姓氏），姓氏（姓氏或姓氏），用户名，社会保险号等。当然，Principals 在应用程序中最好是惟一的。
  • Credentials 通常是仅由 Subject 知道的秘密值，用作他们实际上“拥有”所主张身份的佐证 凭据的一些常见示例是密码，生物特征数据（例如指纹和视网膜扫描）以及 X.509 证书。

• SecurityManager - 安全管理。它是 Shiro 的核心，所有与安全有关的操作（认证、授权、及会话、缓存的管理）都与 SecurityManager 交互，且它管理着所有 Subject。

• Realm - 域。用于访问安全相关数据，可以视为应用自身的数据源，需要开发者自己实现。Shiro 会通过 Realm 获取安全数据（如用户、角色、权限），就是说 SecurityManager 要验证用户身份，那么它需要从 Realm 获取相应的用户进行比较以确定用户身份是否合法；也需要从 Realm 得到用户相应的角色/权限进行验证用户是否能进行操作；可以把 Realm 看成 DataSource，即安全数据源。

SecurityManager

SecurityManager 是 Shiro 框架核心中的核心，它相当于 Shiro 的总指挥，负责调度所有行为，包括：认证、授权、获取安全数据（调用 Realm）、会话管理等。

SecurityManager 聚合了以下组件：

• Authenticator - 认证器，负责认证。如果用户需要定制认证策略，可以实现此接口。
• Authorizer - 授权器，负责权限控制。用来决定主体是否有权限进行相应的操作；即控制着用户能访问应用中的哪些功能；
• SessionManager - 会话管理器。Shiro 抽象了一个自己的 Session 来管理主体与应用之间交互的数据。
• SessionDAO - 会话 DAO 用于存储会话，需要用户自己实现。
• CacheManager - 缓存控制器。用于管理如用户、角色、权限等信息的缓存。
• Cryptography - 密码器。用于对数据加密、解密。

二、Shiro 认证

认证 Subject

验证 Subject 的过程可以有效地分为三个不同的步骤：

（1）收集 Subject 提交的 Principals 和 Credentials

1
2
3
4
5

//Example using most common scenario of username/password pair:
UsernamePasswordToken token = new UsernamePasswordToken(username, password);

//"Remember Me" built-in:
token.setRememberMe(true);

（2）提交 Principals 和 Credentials 以进行身份验证。

1
2
3

Subject currentUser = SecurityUtils.getSubject();

currentUser.login(token);

（3）如果提交成功，则允许访问，否则重试身份验证或阻止访问。

1
2
3
4
5
6
7
8
9
10

try {
    currentUser.login(token);
} catch ( UnknownAccountException uae ) { ...
} catch ( IncorrectCredentialsException ice ) { ...
} catch ( LockedAccountException lae ) { ...
} catch ( ExcessiveAttemptsException eae ) { ...
} ... catch your own ...
} catch ( AuthenticationException ae ) {
    //unexpected error?
}

Remembered 和 Authenticated

• Remembered - 记住我。被记住的 Subject 不是匿名的，并且具有已知的身份（即 subject.getPrincipals() 是非空的）。 但是，在先前的会话期间，通过先前的身份验证会记住此身份。 如果 subject.isRemembered() 返回 true，则认为该主题已被记住。
• Authenticated - 已认证。已认证的 Subject 是在当前会话期间已成功认证的 Subject。 如果 subject.isAuthenticated() 返回 true，则认为该 Subject 已通过身份验证。

登出

当 Subject 与应用程序完成交互后，可以调用 subject.logout() 登出，即放弃所有标识信息。

1

currentUser.logout();

认证流程

1. 应用程序代码调用 Subject.login 方法，传入构造的 AuthenticationToken 实例，该实例代表最终用户的 Principals 和 Credentials。

2. Subject 实例（通常是 DelegatingSubject（或子类））通过调用 securityManager.login（token）委托应用程序的 SecurityManager，在此处开始实际的身份验证工作。

3. SecurityManager 接收令牌，并通过调用 authenticator.authenticate（token）来简单地委派给其内部 Authenticator 实例。这几乎总是一个 ModularRealmAuthenticator 实例，它支持在身份验证期间协调一个或多个 Realm 实例。

4. 如果为该应用程序配置了多个 Realm，则 ModularRealmAuthenticator 实例将利用其配置的 AuthenticationStrategy 发起多域验证尝试。在调用领域进行身份验证之前，期间和之后，将调用 AuthenticationStrategy 以使其对每个领域的结果做出反应。

5. 请咨询每个已配置的 Realm，以查看其是否支持提交的 AuthenticationToken。 如果是这样，将使用提交的令牌调用支持 Realm 的 getAuthenticationInfo 方法。 getAuthenticationInfo 方法有效地表示对该特定 Realm 的单个身份验证尝试。

认证策略

当为一个应用程序配置两个或多个领域时，ModularRealmAuthenticator 依赖于内部 AuthenticationStrategy 组件来确定认证尝试成功或失败的条件。

例如，如果只有一个 Realm 成功地对 AuthenticationToken 进行身份验证，而所有其他 Realm 都失败了，那么该身份验证尝试是否被视为成功？还是必须所有领域都成功进行身份验证才能将整体尝试视为成功？或者，如果某个领域成功通过身份验证，是否有必要进一步咨询其他领域？ AuthenticationStrategy 根据应用程序的需求做出适当的决定。

AuthenticationStrategy 是无状态组件，在尝试进行身份验证时会被查询 4 次（这 4 种交互所需的任何必要状态都将作为方法参数给出）：

• 在任何领域被调用之前
• 在调用单个 Realm 的 getAuthenticationInfo 方法之前
• 在调用单个 Realm 的 getAuthenticationInfo 方法之后
• 在所有领域都被调用之后

AuthenticationStrategy 还负责汇总每个成功 Realm 的结果，并将它们“捆绑”成单个 AuthenticationInfo 表示形式。最终的聚合 AuthenticationInfo 实例是 Authenticator 实例返回的结果，也是 Shiro 用来表示主体的最终身份（也称为委托人）的东西。

:link: 更多认证细节可以参考：Apache Shiro Authentication

三、Shiro 授权

授权，也称为访问控制，是管理对资源的访问的过程。 换句话说，控制谁有权访问应用程序中的内容。

授权元素

授权有三个核心要素：权限、角色和用户。

权限

权限示例：

• 打开一个文件
• 查看 /user/list web 页面
• 查询记录
• 删除一条记录
• …

大多数资源都支持一般的 CRUD 操作。除此以外，对于一些特定的资源，任何有意义的行为都是可以的。基本的设计思路是：权限控制，至少是基于资源和行为。

角色

角色是一个命名实体，通常代表一组行为或职责。这些行为会转化为：谁可以在应用程序中执行哪些行为？谁不可以在程序中执行哪些行为？

角色通常是分配给用户帐户的，因此通过关联，用户可以获得自身角色所赋予的权限。

用户

用户本质上是应用程序的“用户”。

用户（即 Shiro 的 Subject）通过与角色或直接权限的关联在应用程序中执行某些行为。

基于角色的授权

如果授权是基于角色赋予权限的数据模型，编程模式如下：

【示例一】

1
2
3
4
5
6
7

Subject currentUser = SecurityUtils.getSubject();

if (currentUser.hasRole("administrator")) {
    //show the admin button
} else {
    //don't show the button?  Grey it out?
}

【示例二】

1
2
3
4
5
6

Subject currentUser = SecurityUtils.getSubject();

// 检查当前 Subject 是否有某种权限
// 如果有，直接跳过；如果没有，Shiro 会抛出 AuthorizationException
currentUser.checkRole("bankTeller");
openBankAccount();

提示：方式二相比方式一，代码更简洁

基于权限的授权

更好的授权策略通常是基于权限的授权。基于权限的授权，由于它和应用程序的原始功能（针对具体资源上的行为）紧密相关，所以基于权限的授权源代码会在功能更改时同步更改（而不是在安全策略发生更改时）。 这意味着与类似的基于角色的授权代码相比，修改代码的影响面要小得多。

【示例】基于对象的权限检查

1
2
3
4
5
6
7
8
9

Permission printPermission = new PrinterPermission("laserjet4400n", "print");

Subject currentUser = SecurityUtils.getSubject();

if (currentUser.isPermitted(printPermission)) {
    //show the Print button
} else {
    //don't show the button?  Grey it out?
}

在对象中存储权限控制信息，但这种方式较为繁重

【示例】字符串定义权限控制信息

1
2
3
4
5
6
7

Subject currentUser = SecurityUtils.getSubject();

if (currentUser.isPermitted("printer:print:laserjet4400n")) {
    //show the Print button
} else {
    //don't show the button?  Grey it out?
}

使用 : 分隔，表示资源类型、行为、资源 ID，Shiro 提供了默认实现： org.apache.shiro.authz.permission.WildcardPermission。

这种权限控制方式的好处在于：轻量、灵活。

基于注解的授权

Shiro 提供了一些用于授权的注解，来进一步简化授权代码。

@RequiresAuthentication

@RequiresAuthentication 注解要求当前 Subject 必须是已认证用户才可以访问被修饰的方法。

【示例】

1
2
3
4
5
6

@RequiresAuthentication
public void updateAccount(Account userAccount) {
    //this method will only be invoked by a
    //Subject that is guaranteed authenticated
    ...
}

@RequiresGuest

@RequiresGuest 注解要求当前 Subject 的角色是 guest 才可以访问被修饰的方法。

授权流程

1. 应用程序或框架代码调用任何 Subject 的 hasRole*，checkRole*，isPermitted* 或 checkPermission* 方法，并传入所需的权限或角色。

2. Subject 实例，通常是 DelegatingSubject（或子类），通过调用 securityManager 几乎相同的各自 hasRole*，checkRole*，isPermitted* 或 checkPermission* 方法来委托 SecurityManager （实现了 org.apache.shiro.authz.Authorizer 接口）处理授权。

3. SecurityManager 通过调用授权者各自的 hasRole*，checkRole*，isPermitted* 或 checkPermission* 方法来中继/委托其内部的 org.apache.shiro.authz.Authorizer 实例。默认情况下，authorizer 实例是 ModularRealmAuthorizer 实例，该实例支持在任何授权操作期间协调一个或多个 Realm 实例。

4. 检查每个已配置的 Realm，以查看其是否实现相同的 Authorizer 接口。如果是这样，则将调用 Realm 各自的 hasRole*，checkRole*，isPermitted* 或 checkPermission* 方法。

:link: 更多授权细节可以参考：Apache Shiro Authorization

四、Shiro 会话管理

Shiro 提供了一套独特的会话管理方案：其 Session 可以使用 Java SE 程序，也可以使用于 Java Web 程序。

在 Shiro 中，SessionManager 负责管理应用所有 Subject 的会话，如：创建、删除、失效、验证等。

【示例】会话使用示例

1
2
3
4

Subject currentUser = SecurityUtils.getSubject();

Session session = currentUser.getSession();
session.setAttribute( "someKey", someValue);

会话超时

默认情况下，Shiro 中的会话有效期为 30 分钟，超时后，该会话将被 Shiro 视为无效。

可以通过 globalSessionTimeout 方法设置 Shiro 会话超时时间。

会话监听

Shiro 提供了 SessionListener 接口（或 SessionListenerAdapter 接口），用于监听重要的会话事件，并允许使用者在事件触发时做定制化处理。

【示例】

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public class ShiroSessionListener implements SessionListener {

    private final Logger log = LoggerFactory.getLogger(this.getClass());

    private final AtomicInteger sessionCount = new AtomicInteger(0);

    @Override
    public void onStart(Session session) {
        sessionCount.incrementAndGet();
    }

    @Override
    public void onStop(Session session) {
        sessionCount.decrementAndGet();
    }

    @Override
    public void onExpiration(Session session) {
        sessionCount.decrementAndGet();
    }
}

会话存储

大多数情况下，应用需要保存会话信息，以便在稍后可以使用它。

Shiro 提供了 SessionManager 接口，负责将针对会话的 CRUD 操作委派给内部组件 SessionDAO，该组件反映了数据访问对象（DAO）设计模式。

:bell: 注意：由于会话通常具有时效性，所以一般会话天然适合存储于缓存中。存储于 Redis 中是一个不错的选择。

五、Realm

Realm 是 Shiro 访问程序安全相关数据（如：用户、角色、权限）的接口。

Realm 是有开发者自己实现的，开发者可以通过实现 Realm 接口，接入应用的数据源，如：JDBC、文件、Nosql 等等。

认证令牌

Shiro 支持身份验证令牌。在咨询 Realm 进行认证尝试之前，将调用其支持方法。 如果返回值为 true，则仅会调用其 getAuthenticationInfo(token) 方法。通常，Realm 会检查所提交令牌的类型（接口或类），以查看其是否可以处理它。

令牌认证处理流程如下：

1. 检查用于标识 principal 的令牌（帐户标识信息）。
2. 根据 principal，在数据源中查找相应的帐户数据。
3. 确保令牌提供的凭证与数据存储中存储的凭证匹配。
4. 如果 credentials 匹配，则返回 AuthenticationInfo 实例。
5. 如果 credentials 不匹配，则抛出 AuthenticationException 异常。

加密

通过前文，可以了解：Shiro 需要通过一对 principal 和 credentials 来确认身份是否匹配（即认证）。

一般来说，成熟软件是不允许存储账户、密码这些敏感数据时，使用明文存储。所以，通常要将密码加密后存储。

Shiro 提供了一些加密器，其思想就是用 MD5、SHA 这种数字签名算法，加 Salt，然后转为 Base64 字符串。为了避免被暴力破解，Shiro 使用多次加密的方式获得最终的 credentials 字符串。

【示例】Shiro 加密密码示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

import org.apache.shiro.crypto.hash.Sha256Hash;
import org.apache.shiro.crypto.RandomNumberGenerator;
import org.apache.shiro.crypto.SecureRandomNumberGenerator;
...

//We'll use a Random Number Generator to generate salts.  This
//is much more secure than using a username as a salt or not
//having a salt at all.  Shiro makes this easy.
//
//Note that a normal app would reference an attribute rather
//than create a new RNG every time:
RandomNumberGenerator rng = new SecureRandomNumberGenerator();
Object salt = rng.nextBytes();

//Now hash the plain-text password with the random salt and multiple
//iterations and then Base64-encode the value (requires less space than Hex):
String hashedPasswordBase64 = new Sha256Hash(plainTextPassword, salt, 1024).toBase64();

User user = new User(username, hashedPasswordBase64);
//save the salt with the new account.  The HashedCredentialsMatcher
//will need it later when handling login attempts:
user.setPasswordSalt(salt);
userDAO.create(user);

六、配置

过滤链

运行 Web 应用程序时，Shiro 将创建一些有用的默认 Filter 实例。

RememberMe

1
2
3

UsernamePasswordToken token = new UsernamePasswordToken(username, password);
token.setRememberMe(true);
SecurityUtils.getSubject().login(token);

参考资料

• Shiro 官方文档
• 跟我学 Shiro
• The New RBAC: Resource-Based Access Control

Spring Security 快速入门

快速开始

参考：Securing a Web Application

核心 API

设计原理

Spring Security 对于 Servlet 的支持基于过滤链（FilterChain）实现。

Spring 提供了一个名为 DelegatingFilterProxy 的 Filter 实现，该实现允许在 Servlet 容器的生命周期和 Spring 的 ApplicationContext 之间进行桥接。 Servlet 容器允许使用其自己的标准注册 Filters，但它不了解 Spring 定义的 Bean。 DelegatingFilterProxy 可以通过标准的 Servlet 容器机制进行注册，但是可以将所有工作委托给实现 Filter 的 Spring Bean。

1
2
3
4
5
6
7

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
    // Lazily get Filter that was registered as a Spring Bean
    // For the example in DelegatingFilterProxy delegate is an instance of Bean Filter0
    Filter delegate = getFilterBean(someBeanName);
    // delegate work to the Spring Bean
    delegate.doFilter(request, response);
}

FilterChainProxy 使用 SecurityFilterChain 确定应对此请求调用哪些 Spring Security 过滤器。

SecurityFilterChain 中的安全过滤器通常是 Bean，但它们是使用 FilterChainProxy 而不是 DelegatingFilterProxy 注册的。

实际上，FilterChainProxy 可用于确定应使用哪个 SecurityFilterChain。如果您的应用程序可以为不同的模块提供完全独立的配置。

ExceptionTranslationFilter 可以将 AccessDeniedException 和 AuthenticationException 转换为 HTTP 响应。

核心源码：

1
2
3
4
5
6
7
8
9

try {
    filterChain.doFilter(request, response);
} catch (AccessDeniedException | AuthenticationException e) {
    if (!authenticated || e instanceof AuthenticationException) {
        startAuthentication();
    } else {
        accessDenied();
    }
}

认证

数据模型

Spring Security 框架中的认证数据模型如下：

• Authentication - 认证信息实体。
  • principal - 用户标识。如：用户名、账户名等。通常是 UserDetails 的实例（后面详细讲解）。
  • credentials - 认证凭证。如：密码等。
  • authorities - 授权信息。如：用户的角色、权限等信息。
• SecurityContext - 安全上下文。包含一个 Authentication 对象。
• SecurityContextHolder - 安全上下文持有者。用于存储认证信息。

【示例】注册认证信息

1
2
3
4
5

SecurityContext context = SecurityContextHolder.createEmptyContext();
Authentication authentication =
    new TestingAuthenticationToken("username", "password", "ROLE_USER");
context.setAuthentication(authentication);
SecurityContextHolder.setContext(context);

【示例】访问认证信息

认证基本流程

AbstractAuthenticationProcessingFilter 用作验证用户凭据的基本过滤器。 在对凭证进行身份验证之前，Spring Security 通常使用 AuthenticationEntryPoint 请求凭证。

• （1）当用户提交其凭据时，AbstractAuthenticationProcessingFilter 从要验证的 HttpServletRequest 创建一个 Authentication。创建的身份验证类型取决于 AbstractAuthenticationProcessingFilter 的子类。例如，UsernamePasswordAuthenticationFilter 根据在 HttpServletRequest 中提交的用户名和密码来创建 UsernamePasswordAuthenticationToken。
• （2）接下来，将身份验证传递到 AuthenticationManager 进行身份验证。
• （3）如果身份验证失败，则认证失败
  • 清除 SecurityContextHolder。
  • 调用 RememberMeServices.loginFail。如果没有配置 remember me，则为空。
  • 调用 AuthenticationFailureHandler。
• （4）如果身份验证成功，则认证成功。
  • 如果是新的登录，则通知 SessionAuthenticationStrategy。
  • 身份验证是在 SecurityContextHolder 上设置的。之后，SecurityContextPersistenceFilter 将 SecurityContext 保存到 HttpSession 中。
  • 调用 RememberMeServices.loginSuccess。如果没有配置 remember me，则为空。
  • ApplicationEventPublisher 发布一个 InteractiveAuthenticationSuccessEvent。

用户名/密码认证

读取用户名和密码的方式：

• 表单
• 基本认证
• 数字认证

存储机制

• 内存
• JDBC
• UserDetailsService
• LDAP

表单认证

spring security 支持通过从 html 表单获取登录时提交的用户名、密码。

一旦，登录信息被提交，UsernamePasswordAuthenticationFilter 就会验证用户名和密码。

基本认证

1
2
3
4
5

protected void configure(HttpSecurity http) {
    http
        // ...
        .httpBasic(withDefaults());
}

内存认证

InMemoryUserDetailsManager 实现了 UserDetailsService ，提供了基本的用户名、密码认证，其认证数据存储在内存中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

@Bean
public UserDetailsService users() {
    // The builder will ensure the passwords are encoded before saving in memory
    UserBuilder users = User.withDefaultPasswordEncoder();
    UserDetails user = users
        .username("user")
        .password("password")
        .roles("USER")
        .build();
    UserDetails user = users
        .username("admin")
        .password("password")
        .roles("USER", "ADMIN")
        .build();
    return new InMemoryUserDetailsManager(user, admin);
}

JDBC 认证

JdbcUserDetailsManager 实现了 UserDetailsService ，提供了基本的用户名、密码认证，其认证数据存储在关系型数据库中，通过 JDBC 方式访问。

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

@Bean
UserDetailsManager users(DataSource dataSource) {
    UserDetails user = User.builder()
        .username("user")
        .password("{bcrypt}$2a$10$GRLdNijSQMUvl/au9ofL.eDwmoohzzS7.rmNSJZ.0FxO/BTk76klW")
        .roles("USER")
        .build();
    UserDetails admin = User.builder()
        .username("admin")
        .password("{bcrypt}$2a$10$GRLdNijSQMUvl/au9ofL.eDwmoohzzS7.rmNSJZ.0FxO/BTk76klW")
        .roles("USER", "ADMIN")
        .build();
    JdbcUserDetailsManager users = new JdbcUserDetailsManager(dataSource);
    users.createUser()
}

基本的 scheam：

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

create table users(
    username varchar_ignorecase(50) not null primary key,
    password varchar_ignorecase(50) not null,
    enabled boolean not null
);

create table authorities (
    username varchar_ignorecase(50) not null,
    authority varchar_ignorecase(50) not null,
    constraint fk_authorities_users foreign key(username) references users(username)
);
create unique index ix_auth_username on authorities (username,authority);

UserDetailsService

UserDetails 由 UserDetailsService 返回。 DaoAuthenticationProvider 验证 UserDetails，然后返回身份验证，该身份验证的主体是已配置的 UserDetailsService 返回的 UserDetails。

DaoAuthenticationProvider 使用 UserDetailsService 检索用户名，密码和其他用于使用用户名和密码进行身份验证的属性。 Spring Security 提供 UserDetailsService 的内存中和 JDBC 实现。

您可以通过将自定义 UserDetailsService 公开为 bean 来定义自定义身份验证。

PasswordEncoder

Spring Security 的 servlet 支持通过与 PasswordEncoder 集成来安全地存储密码。 可以通过公开一个 PasswordEncoder Bean 来定制 Spring Security 使用的 PasswordEncoder 实现。

Remember-Me

Spring Boot 集成

@EnableWebSecurity 和 @Configuration 注解一起使用, 注解 WebSecurityConfigurer 类型的类。

或者利用@EnableWebSecurity注解继承 WebSecurityConfigurerAdapter 的类，这样就构成了 Spring Security 的配置。

• configure(WebSecurity)：通过重载该方法，可配置 Spring Security 的 Filter 链。
• configure(HttpSecurity)：通过重载该方法，可配置如何通过拦截器保护请求。

参考资料

• Spring Security Architecture
• Securing a Web Application

Netty 快速入门

Netty 简介

Netty 是一款基于 NIO（Nonblocking I/O，非阻塞 IO）开发的网络通信框架。

Netty 的特性

• 高并发：Netty 是一款基于 NIO（Nonblocking IO，非阻塞 IO）开发的网络通信框架，对比于 BIO（Blocking I/O，阻塞 IO），他的并发性能得到了很大提高。
• 传输快：Netty 的传输依赖于内存零拷贝特性，尽量减少不必要的内存拷贝，实现了更高效率的传输。
• 封装好：Netty 封装了 NIO 操作的很多细节，提供了易于使用调用接口。

核心组件

• Channel：Netty 网络操作抽象类，它除了包括基本的 I/O 操作，如 bind、connect、read、write 等。
• EventLoop：主要是配合 Channel 处理 I/O 操作，用来处理连接的生命周期中所发生的事情。
• ChannelFuture：Netty 框架中所有的 I/O 操作都为异步的，因此我们需要 ChannelFuture 的 addListener()注册一个 ChannelFutureListener 监听事件，当操作执行成功或者失败时，监听就会自动触发返回结果。
• ChannelHandler：充当了所有处理入站和出站数据的逻辑容器。ChannelHandler 主要用来处理各种事件，这里的事件很广泛，比如可以是连接、数据接收、异常、数据转换等。
• ChannelPipeline：为 ChannelHandler 链提供了容器，当 channel 创建时，就会被自动分配到它专属的 ChannelPipeline，这个关联是永久性的。

Netty 有两种发送消息的方式：

• 直接写入 Channel 中，消息从 ChannelPipeline 当中尾部开始移动；
• 写入和 ChannelHandler 绑定的 ChannelHandlerContext 中，消息从 ChannelPipeline 中的下一个 ChannelHandler 中移动。

高性能

Netty 高性能表现在哪些方面：

• NIO 线程模型：同步非阻塞，用最少的资源做更多的事。
• 内存零拷贝：尽量减少不必要的内存拷贝，实现了更高效率的传输。
• 内存池设计：申请的内存可以重用，主要指直接内存。内部实现是用一颗二叉查找树管理内存分配情况。
• 串形化处理读写：避免使用锁带来的性能开销。
• 高性能序列化协议：支持 protobuf 等高性能序列化协议。

零拷贝

传统意义的拷贝

是在发送数据的时候，传统的实现方式是：

File.read(bytes)

Socket.send(bytes)

这种方式需要四次数据拷贝和四次上下文切换：

1. 数据从磁盘读取到内核的 read buffer

2. 数据从内核缓冲区拷贝到用户缓冲区

3. 数据从用户缓冲区拷贝到内核的 socket buffer

4. 数据从内核的 socket buffer 拷贝到网卡接口（硬件）的缓冲区

零拷贝的概念

明显上面的第二步和第三步是非必要的，通过 java 的 FileChannel.transferTo 方法，可以避免上面两次多余的拷贝（当然这需要底层操作系统支持）

• 调用 transferTo，数据从文件由 DMA 引擎拷贝到内核 read buffer
• 接着 DMA 从内核 read buffer 将数据拷贝到网卡接口 buffer

上面的两次操作都不需要 CPU 参与，所以就达到了零拷贝。

Netty 中的零拷贝

主要体现在三个方面：

bytebuffer

Netty 发送和接收消息主要使用 bytebuffer，bytebuffer 使用对外内存（DirectMemory）直接进行 Socket 读写。

原因：如果使用传统的堆内存进行 Socket 读写，JVM 会将堆内存 buffer 拷贝一份到直接内存中然后再写入 socket，多了一次缓冲区的内存拷贝。DirectMemory 中可以直接通过 DMA 发送到网卡接口

Composite Buffers

传统的 ByteBuffer，如果需要将两个 ByteBuffer 中的数据组合到一起，我们需要首先创建一个 size=size1+size2 大小的新的数组，然后将两个数组中的数据拷贝到新的数组中。但是使用 Netty 提供的组合 ByteBuf，就可以避免这样的操作，因为 CompositeByteBuf 并没有真正将多个 Buffer 组合起来，而是保存了它们的引用，从而避免了数据的拷贝，实现了零拷贝。

对于 FileChannel.transferTo 的使用

Netty 中使用了 FileChannel 的 transferTo 方法，该方法依赖于操作系统实现零拷贝。

Netty 流程

应用

Netty 是一个广泛使用的 Java 网络编程框架。很多著名软件都使用了它，如：Dubbo、Cassandra、Elasticsearch、Vert.x 等。

有了 Netty，你可以实现自己的 HTTP 服务器，FTP 服务器，UDP 服务器，RPC 服务器，WebSocket 服务器，Redis 的 Proxy 服务器，MySQL 的 Proxy 服务器等等。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

public class NettyOioServer {

    public void server(int port) throws Exception {
        final ByteBuf buf = Unpooled.unreleasableBuffer(
                Unpooled.copiedBuffer("Hi!\r\n", Charset.forName("UTF-8")));
        EventLoopGroup group = new OioEventLoopGroup();
        try {
            ServerBootstrap b = new ServerBootstrap();        //1

            b.group(group)                                    //2
             .channel(OioServerSocketChannel.class)
             .localAddress(new InetSocketAddress(port))
             .childHandler(new ChannelInitializer<SocketChannel>() {//3
                 @Override
                 public void initChannel(SocketChannel ch)
                     throws Exception {
                     ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {            //4
                         @Override
                         public void channelActive(ChannelHandlerContext ctx) throws Exception {
                             ctx.writeAndFlush(buf.duplicate()).addListener(ChannelFutureListener.CLOSE);//5
                         }
                     });
                 }
             });
            ChannelFuture f = b.bind().sync();  //6
            f.channel().closeFuture().sync();
        } finally {
            group.shutdownGracefully().sync();        //7
        }
    }
}

参考资料

• 官方
  • Netty 官网
  • Netty Github
• 文章
  • Netty 入门教程——认识 Netty
  • 彻底理解 Netty，这一篇文章就够了
  • Java 200+ 面试题补充 ② Netty 模块

Java 缓存中间件

关键词：Spring Cache、J2Cache、JetCache

一 、JSR 107

JSR107 中制订了 Java 缓存的规范。

因此，在很多缓存框架、缓存库中，其 API 都参考了 JSR 107 规范。

Java Caching 定义了 5 个核心接口

• CachingProvider - 定义了创建、配置、获取、管理和控制多个 CacheManager。一个应用可以在运行期访问多个 CachingProvider。
• CacheManager - 定义了创建、配置、获取、管理和控制多个唯一命名的 Cache，这些 Cache 存在于 CacheManager 的上下文中。一个 CacheManager 仅被一个 CachingProvider 所拥有。
• Cache - 是一个类似 Map 的数据结构并临时存储以 Key 为索引的值。一个 Cache 仅被一个 CacheManager 所拥有。
• Entry - 是一个存储在 Cache 中的 key-value 对。
• Expiry - 每一个存储在 Cache 中的条目有一个定义的有效期，即 Expiry Duration。一旦超过这个时间，条目为过期的状态。一旦过期，条目将不可访问、更新和删除。缓存有效期可以通过 ExpiryPolicy 设置。

二、Spring Cache

详见：Spring Cache 官方文档

Spring 作为 Java 开发最著名的框架，也提供了缓存功能的框架—— Spring Cache。

Spring 支持基于注释（annotation）的缓存（cache）技术，它本质上不是一个具体的缓存实现方案（例如：EHCache 或 OSCache），而是一个对缓存使用的抽象，通过在既有代码中添加少量它定义的各种 annotation，即能够达到缓存方法的返回对象的效果。

Spring Cache 的特点：

• 通过缓存注解即可支持缓存功能
• 支持 Spring EL 表达式
• 支持 AspectJ
• 支持自定义 key 和缓存管理

开启缓存注解

Spring 为缓存功能提供了注解功能，但是你必须启动注解。

有两种方式：

（一）使用标记注解 @EnableCaching

这种方式对于 Spring 或 Spring Boot 项目都适用。

1
2
3
4

@Configuration
@EnableCaching
public class AppConfig {
}

（二）在 xml 中声明

1

<cache:annotation-driven cache-manager="cacheManager"/>

spring 缓存注解 API

Spring 对缓存的支持类似于对事务的支持。

首先使用注解标记方法，相当于定义了切点，然后使用 Aop 技术在这个方法的调用前、调用后获取方法的入参和返回值，进而实现了缓存的逻辑。

@Cacheable

@Cacheable 用于触发缓存。

表明所修饰的方法是可以缓存的：当第一次调用这个方法时，它的结果会被缓存下来，在缓存的有效时间内，以后访问这个方法都直接返回缓存结果，不再执行方法中的代码段。

这个注解可以用condition属性来设置条件，如果不满足条件，就不使用缓存能力，直接执行方法。

可以使用key属性来指定 key 的生成规则。

@CachePut

@CachePut 用于更新缓存。

与@Cacheable不同，@CachePut不仅会缓存方法的结果，还会执行方法的代码段。

它支持的属性和用法都与@Cacheable一致。

@CacheEvict

@CacheEvict 用于清除缓存。

与@Cacheable功能相反，@CacheEvict表明所修饰的方法是用来删除失效或无用的缓存数据。

下面是@Cacheable、@CacheEvict和@CachePut基本使用方法的一个集中展示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

@Service
public class UserService {
    // @Cacheable可以设置多个缓存，形式如：@Cacheable({"books", "isbns"})
    @Cacheable(value={"users"}, key="#user.id")
    public User findUser(User user) {
        return findUserInDB(user.getId());
    }

    @Cacheable(value = "users", condition = "#user.getId() <= 2")
    public User findUserInLimit(User user) {
        return findUserInDB(user.getId());
    }

    @CachePut(value = "users", key = "#user.getId()")
    public void updateUser(User user) {
        updateUserInDB(user);
    }

    @CacheEvict(value = "users")
    public void removeUser(User user) {
        removeUserInDB(user.getId());
    }

    @CacheEvict(value = "users", allEntries = true)
    public void clear() {
        removeAllInDB();
    }
}

@Caching

@Caching 用于组合定义多种缓存功能。

如果需要使用同一个缓存注解（@Cacheable、@CacheEvict或@CachePut）多次修饰一个方法，就需要用到@Caching。

1
2

@Caching(evict = { @CacheEvict("primary"), @CacheEvict(cacheNames="secondary", key="#p0") })
public Book importBooks(String deposit, Date date)

@CacheConfig

@CacheConfig 用于定义公共缓存配置。

与前面的缓存注解不同，这是一个类级别的注解。

如果类的所有操作都是缓存操作，你可以使用@CacheConfig来指定类，省去一些配置。

1
2
3
4
5

@CacheConfig("books")
public class BookRepositoryImpl implements BookRepository {
 @Cacheable
 public Book findBook(ISBN isbn) {...}
}

三、Spring Boot Cache

详见：Spring Boot Cache 特性官方文档

Spring Boot Cache 是在 Spring Cache 的基础上做了封装，使得使用更为便捷。

Spring Boot Cache 快速入门

（1）引入依赖

1
2
3
4
5
6
7
8
9
10

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-cache</artifactId>
</dependency>

<!-- 按序引入需要的缓存库 -->
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

（2）缓存配置

例如，选用缓存为 redis，则需要配置 redis 相关的配置项（如：数据源、连接池等配置信息）

1
2
3
4
5
6
7
8
9
10

# 缓存类型，支持类型：GENERIC、JCACHE、EHCACHE、HAZELCAST、INFINISPAN、COUCHBASE、REDIS、CAFFEINE、SIMPLE
spring.cache.type = redis
# 全局缓存时间
spring.cache.redis.time-to-live = 60s

# Redis 配置
spring.redis.database = 0
spring.redis.host = localhost
spring.redis.port = 6379
spring.redis.password =

（3）使用 @EnableCaching 开启缓存

1
2
3
4
5

@EnableCaching
@SpringBootApplication
public class Application {
    // ...
}

（4）缓存注解（@Cacheable、@CachePut、@CacheEvit 等）使用方式与 Spring Cache 完全一样

四、JetCache

JetCache 是一个基于 Java 的缓存系统封装，提供统一的 API 和注解来简化缓存的使用。 JetCache 提供了比 SpringCache 更加强大的注解，可以原生的支持 TTL、两级缓存、分布式自动刷新，还提供了Cache接口用于手工缓存操作。 当前有四个实现，RedisCache、TairCache（此部分未在 github 开源）、CaffeineCache(in memory)和一个简易的LinkedHashMapCache(in memory)，要添加新的实现也是非常简单的。

详见：jetcache Github

jetcache 快速入门

如果使用 Spring Boot，可以按如下的方式配置（这里使用了 jedis 客户端连接 redis，如果需要集群、读写分离、异步等特性支持请使用lettuce客户端）。

（1）引入 POM

1
2
3
4
5

<dependency>
    <groupId>com.alicp.jetcache</groupId>
    <artifactId>jetcache-starter-redis</artifactId>
    <version>2.5.14</version>
</dependency>

（2）配置

配置一个 spring boot 风格的 application.yml 文件，把他放到资源目录中

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

jetcache:
  statIntervalMinutes: 15
  areaInCacheName: false
  local:
    default:
      type: linkedhashmap
      keyConvertor: fastjson
  remote:
    default:
      type: redis
      keyConvertor: fastjson
      valueEncoder: java
      valueDecoder: java
      poolConfig:
        minIdle: 5
        maxIdle: 20
        maxTotal: 50
      host: 127.0.0.1
      port: 6379

（3）开启缓存

然后创建一个 App 类放在业务包的根下，EnableMethodCache，EnableCreateCacheAnnotation 这两个注解分别激活 Cached 和 CreateCache 注解，其他和标准的 Spring Boot 程序是一样的。这个类可以直接 main 方法运行。

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

package com.company.mypackage;

import com.alicp.jetcache.anno.config.EnableCreateCacheAnnotation;
import com.alicp.jetcache.anno.config.EnableMethodCache;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
@EnableMethodCache(basePackages = "com.company.mypackage")
@EnableCreateCacheAnnotation
public class MySpringBootApp {
    public static void main(String[] args) {
        SpringApplication.run(MySpringBootApp.class);
    }
}

（4）API 基本使用

创建缓存实例

通过 @CreateCache 注解创建一个缓存实例，默认超时时间是 100 秒

1
2

@CreateCache(expire = 100)
private Cache<Long, UserDO> userCache;

用起来就像 map 一样

1
2
3

UserDO user = userCache.get(123L);
userCache.put(123L, user);
userCache.remove(123L);

创建一个两级（内存+远程）的缓存，内存中的元素个数限制在 50 个。

1
2

@CreateCache(name = "UserService.userCache", expire = 100, cacheType = CacheType.BOTH, localLimit = 50)
private Cache<Long, UserDO> userCache;

name 属性不是必须的，但是起个名字是个好习惯，展示统计数据的使用，会使用这个名字。如果同一个 area 两个 @CreateCache 的 name 配置一样，它们生成的 Cache 将指向同一个实例。

创建方法缓存

使用 @Cached 方法可以为一个方法添加上缓存。JetCache 通过 Spring AOP 生成代理，来支持缓存功能。注解可以加在接口方法上也可以加在类方法上，但需要保证是个 Spring bean。

1
2
3
4

public interface UserService {
    @Cached(name="UserService.getUserById", expire = 3600)
    User getUserById(long userId);
}

五、j2cache

六、总结

使用缓存框架，使得开发缓存功能非常便捷。

如果你的系统只需要使用一种缓存，那么推荐使用 Spring Boot Cache。Spring Boot Cache 在 Spring Cache 基础上做了封装，使用更简单、方便。

如果你的系统需要使用多级缓存，那么推荐使用 jetcache。

参考资料

• JSR107
• Spring Cache 官方文档
• Spring Boot Cache 特性官方文档
• J2Cache Gitee
• jetcache Github
• jetcache wiki

Ehcache 快速入门

EhCache 是一个纯 Java 的进程内缓存框架，具有快速、精干等特点，是 Hibernate 中默认的 CacheProvider。

一、简介

Ehcache 虽然也支持分布式模式，但是分布式方案不是很好好，建议只将其作为单机的进程内缓存使用。

Ehcache 特性

优点

• 快速、简单
• 支持多种缓存策略：LRU、LFU、FIFO 淘汰算法
• 缓存数据有两级：内存和磁盘，因此无需担心容量问题
• 缓存数据会在虚拟机重启的过程中写入磁盘
• 可以通过 RMI、可插入 API 等方式进行分布式缓存
• 具有缓存和缓存管理器的侦听接口
• 支持多缓存管理器实例，以及一个实例的多个缓存区域
• 提供 Hibernate 的缓存实现

缺点

• 使用磁盘 Cache 的时候非常占用磁盘空间
• 不保证数据的安全
• 虽然支持分布式缓存，但效率不高（通过组播方式，在不同节点之间同步数据）。

Ehcache 集群

Ehcache 目前支持五种集群方式：

• RMI
• JMS
• JGroup
• Terracotta
• Ehcache Server

RMI

使用组播方式通知所有节点同步数据。

如果网络有问题，或某台服务宕机，则存在数据无法同步的可能，导致数据不一致。

JMS

JMS 类似 MQ，所有节点订阅消息，当某节点缓存发生变化，就向 JMS 发消息，其他节点感知变化后，同步数据。

Cache Server

二、快速入门

引入 Ehcache

如果你的项目使用 maven 管理，添加以下依赖到你的 pom.xml 中。

1
2
3
4
5
6

<dependency>
  <groupId>net.sf.ehcache</groupId>
  <artifactId>ehcache</artifactId>
  <version>2.10.2</version>
  <type>pom</type>
</dependency>

如果你的项目不使用 maven 管理，请在 Ehcache 官网下载地址 下载 jar 包。

Spring 提供了对于 Ehcache 接口的封装，可以更简便的使用其功能。接入方式如下：

如果你的项目使用 maven 管理，添加以下依赖到你的pom.xml中。

spring-context-support这个 jar 包中含有 Spring 对于缓存功能的抽象封装接口。

1
2
3
4
5

<dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-context-support</artifactId>
  <version>4.1.4.RELEASE</version>
</dependency>

添加配置文件

（1）在 classpath 下添加 ehcache.xml
添加一个名为 helloworld 的缓存。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

<?xml version="1.0" encoding="UTF-8"?>
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd">

  <!-- 磁盘缓存位置 -->
  <diskStore path="java.io.tmpdir/ehcache"/>

  <!-- 默认缓存 -->
  <defaultCache
          maxEntriesLocalHeap="10000"
          eternal="false"
          timeToIdleSeconds="120"
          timeToLiveSeconds="120"
          maxEntriesLocalDisk="10000000"
          diskExpiryThreadIntervalSeconds="120"
          memoryStoreEvictionPolicy="LRU"/>

  <!-- helloworld缓存 -->
  <cache name="helloworld"
         maxElementsInMemory="1000"
         eternal="false"
         timeToIdleSeconds="5"
         timeToLiveSeconds="5"
         overflowToDisk="false"
         memoryStoreEvictionPolicy="LRU"/>
</ehcache>

Ehcache 工作示例

Ehcache 会自动加载 classpath 根目录下名为 ehcache.xml 文件。

EhcacheDemo 的工作步骤如下：

1. 在 EhcacheDemo 中，我们引用 ehcache.xml 声明的名为 helloworld 的缓存来创建Cache对象；
2. 然后我们用一个键值对来实例化Element对象；
3. 将Element对象添加到Cache；
4. 然后用Cache的 get 方法获取Element对象。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

public class EhcacheDemo {
    public static void main(String[] args) throws Exception {
        // Create a cache manager
        final CacheManager cacheManager = new CacheManager();

        // create the cache called "helloworld"
        final Cache cache = cacheManager.getCache("helloworld");

        // create a key to map the data to
        final String key = "greeting";

        // Create a data element
        final Element putGreeting = new Element(key, "Hello, World!");

        // Put the element into the data store
        cache.put(putGreeting);

        // Retrieve the data element
        final Element getGreeting = cache.get(key);

        // Print the value
        System.out.println(getGreeting.getObjectValue());
    }
}

输出

1

Hello, World!

三、Ehcache API

Element、Cache、CacheManager是 Ehcache 最重要的 API。

• Element - 缓存的元素，它维护着一个键值对。
• Cache - 它是 Ehcache 的核心类，它有多个Element，并被CacheManager管理。它实现了对缓存的逻辑行为。
• CacheManager - Cache的容器对象，并管理着Cache的生命周期。CacheManager 支持两种创建模式：单例（Singleton mode）和实例（InstanceMode）。

创建 CacheManager

下面的代码列举了创建 CacheManager 的五种方式。

使用静态方法create()会以默认配置来创建单例的CacheManager实例。

newInstance()方法是一个工厂方法，以默认配置创建一个新的CacheManager实例。

此外，newInstance()还有几个重载函数，分别可以通过传入String、URL、InputStream参数来加载配置文件，然后创建CacheManager实例。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

// 使用Ehcache默认配置获取单例的CacheManager实例
CacheManager.create();
String[] cacheNames = CacheManager.getInstance().getCacheNames();

// 使用Ehcache默认配置新建一个CacheManager实例
CacheManager.newInstance();
String[] cacheNames = manager.getCacheNames();

// 使用不同的配置文件分别创建一个CacheManager实例
CacheManager manager1 = CacheManager.newInstance("src/config/ehcache1.xml");
CacheManager manager2 = CacheManager.newInstance("src/config/ehcache2.xml");
String[] cacheNamesForManager1 = manager1.getCacheNames();
String[] cacheNamesForManager2 = manager2.getCacheNames();

// 基于classpath下的配置文件创建CacheManager实例
URL url = getClass().getResource("/anotherconfigurationname.xml");
CacheManager manager = CacheManager.newInstance(url);

// 基于文件流得到配置文件，并创建CacheManager实例
InputStream fis = new FileInputStream(new File
("src/config/ehcache.xml").getAbsolutePath());
try {
 CacheManager manager = CacheManager.newInstance(fis);
} finally {
 fis.close();
}

添加缓存

需要强调一点，Cache对象在用addCache方法添加到CacheManager之前，是无效的。

使用 CacheManager 的 addCache 方法可以根据缓存名将 ehcache.xml 中声明的 cache 添加到容器中；它也可以直接将 Cache 对象添加到缓存容器中。

Cache有多个构造函数，提供了不同方式去加载缓存的配置参数。

有时候，你可能需要使用 API 来动态的添加缓存，下面的例子就提供了这样的范例。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

// 除了可以使用xml文件中配置的缓存，你也可以使用API动态增删缓存
// 添加缓存
manager.addCache(cacheName);

// 使用默认配置添加缓存
CacheManager singletonManager = CacheManager.create();
singletonManager.addCache("testCache");
Cache test = singletonManager.getCache("testCache");

// 使用自定义配置添加缓存，注意缓存未添加进CacheManager之前并不可用
CacheManager singletonManager = CacheManager.create();
Cache memoryOnlyCache = new Cache("testCache", 5000, false, false, 5, 2);
singletonManager.addCache(memoryOnlyCache);
Cache test = singletonManager.getCache("testCache");

// 使用特定的配置添加缓存
CacheManager manager = CacheManager.create();
Cache testCache = new Cache(
 new CacheConfiguration("testCache", maxEntriesLocalHeap)
 .memoryStoreEvictionPolicy(MemoryStoreEvictionPolicy.LFU)
 .eternal(false)
 .timeToLiveSeconds(60)
 .timeToIdleSeconds(30)
 .diskExpiryThreadIntervalSeconds(0)
 .persistence(new PersistenceConfiguration().strategy(Strategy.LOCALTEMPSWAP)));
 manager.addCache(testCache);

删除缓存

删除缓存比较简单，你只需要将指定的缓存名传入removeCache方法即可。

1
2

CacheManager singletonManager = CacheManager.create();
singletonManager.removeCache("sampleCache1");

基本缓存操作

Cache 最重要的两个方法就是 put 和 get，分别用来添加 Element 和获取 Element。

Cache 还提供了一系列的 get、set 方法来设置或获取缓存参数，这里不一一列举，更多 API 操作可参考官方 API 开发手册。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

/**
 * 测试：使用默认配置或使用指定配置来创建CacheManager
 *
 * @author Zhang Peng
 */
public class CacheOperationTest {
    private final Logger log = LoggerFactory.getLogger(CacheOperationTest.class);

    /**
     * 使用Ehcache默认配置(classpath下的ehcache.xml)获取单例的CacheManager实例
     */
    @Test
    public void operation() {
        CacheManager manager = CacheManager.newInstance("src/test/resources/ehcache/ehcache.xml");

        // 获得Cache的引用
        Cache cache = manager.getCache("userCache");

        // 将一个Element添加到Cache
        cache.put(new Element("key1", "value1"));

        // 获取Element，Element类支持序列化，所以下面两种方法都可以用
        Element element1 = cache.get("key1");
        // 获取非序列化的值
        log.debug("key:{}, value:{}", element1.getObjectKey(), element1.getObjectValue());
        // 获取序列化的值
        log.debug("key:{}, value:{}", element1.getKey(), element1.getValue());

        // 更新Cache中的Element
        cache.put(new Element("key1", "value2"));
        Element element2 = cache.get("key1");
        log.debug("key:{}, value:{}", element2.getObjectKey(), element2.getObjectValue());

        // 获取Cache的元素数
        log.debug("cache size:{}", cache.getSize());

        // 获取MemoryStore的元素数
        log.debug("MemoryStoreSize:{}", cache.getMemoryStoreSize());

        // 获取DiskStore的元素数
        log.debug("DiskStoreSize:{}", cache.getDiskStoreSize());

        // 移除Element
        cache.remove("key1");
        log.debug("cache size:{}", cache.getSize());

        // 关闭当前CacheManager对象
        manager.shutdown();

        // 关闭CacheManager单例实例
        CacheManager.getInstance().shutdown();
    }
}

四、Ehcache 配置

Ehcache 支持通过 xml 文件和 API 两种方式进行配置。

详情参考：Ehcache 官方 XML 配置手册

xml 配置方式

Ehcache 的CacheManager构造函数或工厂方法被调用时，会默认加载 classpath 下名为ehcache.xml的配置文件。如果加载失败，会加载 Ehcache jar 包中的ehcache-failsafe.xml文件，这个文件中含有简单的默认配置。
ehcache.xml 配置参数说明：

• name：缓存名称。
• maxElementsInMemory：缓存最大个数。
• eternal：缓存中对象是否为永久的，如果是，超时设置将被忽略，对象从不过期。
• timeToIdleSeconds：置对象在失效前的允许闲置时间（单位：秒）。仅当 eternal=false 对象不是永久有效时使用，可选属性，默认值是 0，也就是可闲置时间无穷大。
• timeToLiveSeconds：缓存数据的生存时间（TTL），也就是一个元素从构建到消亡的最大时间间隔值，这只能在元素不是永久驻留时有效，如果该值是 0 就意味着元素可以停顿无穷长的时间。
• maxEntriesLocalDisk：当内存中对象数量达到 maxElementsInMemory 时，Ehcache 将会对象写到磁盘中。
• overflowToDisk：内存不足时，是否启用磁盘缓存。
• diskSpoolBufferSizeMB：这个参数设置 DiskStore（磁盘缓存）的缓存区大小。默认是 30MB。每个 Cache 都应该有自己的一个缓冲区。
• maxElementsOnDisk：硬盘最大缓存个数。
• diskPersistent：是否在 VM 重启时存储硬盘的缓存数据。默认值是 false。
• diskExpiryThreadIntervalSeconds：磁盘失效线程运行时间间隔，默认是 120 秒。
• memoryStoreEvictionPolicy：当达到 maxElementsInMemory 限制时，Ehcache 将会根据指定的策略去清理内存。默认策略是 LRU（最近最少使用）。你可以设置为 FIFO（先进先出）或是 LFU（较少使用）。
• clearOnFlush：内存数量最大时是否清除。

API 配置方式

xml 配置的参数也可以直接通过编程方式来动态的进行配置（dynamicConfig 没有设为 false）。

1
2
3
4
5
6

Cache cache = manager.getCache("sampleCache");
CacheConfiguration config = cache.getCacheConfiguration();
config.setTimeToIdleSeconds(60);
config.setTimeToLiveSeconds(120);
config.setmaxEntriesLocalHeap(10000);
config.setmaxEntriesLocalDisk(1000000);

也可以通过disableDynamicFeatures()方式关闭动态配置开关。配置以后你将无法再以编程方式配置参数。

1
2

Cache cache = manager.getCache("sampleCache");
cache.disableDynamicFeatures();

五、Spring 集成 Ehcache

Spring3.1 开始添加了对缓存的支持。和事务功能的支持方式类似，缓存抽象允许底层使用不同的缓存解决方案来进行整合。

Spring4.1 开始支持 JSR-107 注解。

注：我本人使用的 Spring 版本为 4.1.4.RELEASE，目前 Spring 版本仅支持 Ehcache2.5 以上版本，但不支持 Ehcache3。

绑定 Ehcache

org.springframework.cache.ehcache.EhCacheManagerFactoryBean这个类的作用是加载 Ehcache 配置文件。
org.springframework.cache.ehcache.EhCacheCacheManager这个类的作用是支持 net.sf.ehcache.CacheManager。

spring-ehcache.xml的配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:cache="http://www.springframework.org/schema/cache"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
        http://www.springframework.org/schema/cache
        http://www.springframework.org/schema/cache/spring-cache-3.2.xsd">

  <description>ehcache缓存配置管理文件</description>

  <bean id="ehcache" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
    <property name="configLocation" value="classpath:ehcache/ehcache.xml"/>
  </bean>

  <bean id="cacheManager" class="org.springframework.cache.ehcache.EhCacheCacheManager">
    <property name="cacheManager" ref="ehcache"/>
  </bean>

  <!-- 启用缓存注解开关 -->
  <cache:annotation-driven cache-manager="cacheManager"/>
</beans>

使用 Spring 的缓存注解

开启注解

Spring 为缓存功能提供了注解功能，但是你必须启动注解。
你有两个选择：
(1) 在 xml 中声明
像上一节 spring-ehcache.xml 中的做法一样，使用<cache:annotation-driven/>

1

<cache:annotation-driven cache-manager="cacheManager"/>

(2) 使用标记注解
你也可以通过对一个类进行注解修饰的方式在这个类中使用缓存注解。
范例如下：

1
2
3
4

@Configuration
@EnableCaching
public class AppConfig {
}

注解基本使用方法

Spring 对缓存的支持类似于对事务的支持。
首先使用注解标记方法，相当于定义了切点，然后使用 Aop 技术在这个方法的调用前、调用后获取方法的入参和返回值，进而实现了缓存的逻辑。
下面三个注解都是方法级别：

@Cacheable

表明所修饰的方法是可以缓存的：当第一次调用这个方法时，它的结果会被缓存下来，在缓存的有效时间内，以后访问这个方法都直接返回缓存结果，不再执行方法中的代码段。
这个注解可以用condition属性来设置条件，如果不满足条件，就不使用缓存能力，直接执行方法。
可以使用key属性来指定 key 的生成规则。

@CachePut

与@Cacheable不同，@CachePut不仅会缓存方法的结果，还会执行方法的代码段。
它支持的属性和用法都与@Cacheable一致。

@CacheEvict

与@Cacheable功能相反，@CacheEvict表明所修饰的方法是用来删除失效或无用的缓存数据。
下面是@Cacheable、@CacheEvict和@CachePut基本使用方法的一个集中展示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

@Service
public class UserService {
    // @Cacheable可以设置多个缓存，形式如：@Cacheable({"books", "isbns"})
    @Cacheable(value={"users"}, key="#user.id")
    public User findUser(User user) {
        return findUserInDB(user.getId());
    }

    @Cacheable(value = "users", condition = "#user.getId() <= 2")
    public User findUserInLimit(User user) {
        return findUserInDB(user.getId());
    }

    @CachePut(value = "users", key = "#user.getId()")
    public void updateUser(User user) {
        updateUserInDB(user);
    }

    @CacheEvict(value = "users")
    public void removeUser(User user) {
        removeUserInDB(user.getId());
    }

    @CacheEvict(value = "users", allEntries = true)
    public void clear() {
        removeAllInDB();
    }
}

@Caching

如果需要使用同一个缓存注解（@Cacheable、@CacheEvict或@CachePut）多次修饰一个方法，就需要用到@Caching。

1
2

@Caching(evict = { @CacheEvict("primary"), @CacheEvict(cacheNames="secondary", key="#p0") })
public Book importBooks(String deposit, Date date)

@CacheConfig

与前面的缓存注解不同，这是一个类级别的注解。
如果类的所有操作都是缓存操作，你可以使用@CacheConfig来指定类，省去一些配置。

1
2
3
4
5

@CacheConfig("books")
public class BookRepositoryImpl implements BookRepository {
 @Cacheable
 public Book findBook(ISBN isbn) {...}
}

参考资料

• 官方
  • Ehcache 官网
  • Ehcache Github
• 文章
  • Ehcache 优缺点以及分布式详解
  • Ehcache 详细解读
  • 注释驱动的 Spring cache 缓存介绍
  • Spring 官方文档第 36 章缓存抽象

Java 进程内缓存

关键词：ConcurrentHashMap、LRUHashMap、Guava Cache、Caffeine、Ehcache

一、ConcurrentHashMap

最简单的进程内缓存可以通过 JDK 自带的 HashMap 或 ConcurrentHashMap 实现。

适用场景：不需要淘汰的缓存数据。

缺点：无法进行缓存淘汰，内存会无限制的增长。

二、LRUHashMap

可以通过**继承 LinkedHashMap 来实现一个简单的 LRUHashMap**，即可完成一个简单的 LRU （最近最少使用）算法。

缺点：

• 锁竞争严重，性能比较低。
• 不支持过期时间
• 不支持自动刷新

【示例】LRUHashMap 的简单实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

class LRUCache extends LinkedHashMap {

    private final int max;
    private Object lock;

    public LRUCache(int max) {
        //无需扩容
        super((int) (max * 1.4f), 0.75f, true);
        this.max = max;
        this.lock = new Object();
    }

    /**
     * 重写LinkedHashMap的removeEldestEntry方法即可 在Put的时候判断，如果为true，就会删除最老的
     *
     * @param eldest
     * @return
     */
    @Override
    protected boolean removeEldestEntry(Map.Entry eldest) {
        return size() > max;
    }

    public Object getValue(Object key) {
        synchronized (lock) {
            return get(key);
        }
    }

    public void putValue(Object key, Object value) {
        synchronized (lock) {
            put(key, value);
        }
    }

    public boolean removeValue(Object key) {
        synchronized (lock) {
            return remove(key) != null;
        }
    }

    public boolean removeAll() {
        clear();
        return true;
    }

}

三、Guava Cache

Guava Cache 解决了 LRUHashMap 中的几个缺点。

Guava Cache 提供了基于容量，时间和引用的缓存回收方式。基于容量的方式内部实现采用 LRU 算法，基于引用回收很好的利用了 Java 虚拟机的垃圾回收机制。

其中的缓存构造器 CacheBuilder 采用构建者模式提供了设置好各种参数的缓存对象。缓存核心类 LocalCache 里面的内部类 Segment 与 jdk1.7 及以前的 ConcurrentHashMap 非常相似，分段加锁，减少锁竞争，并且都继承于 ReetrantLock，还有六个队列，以实现丰富的本地缓存方案。Guava Cache 对于过期的 Entry 并没有马上过期(也就是并没有后台线程一直在扫)，而是通过进行读写操作的时候进行过期处理，这样做的好处是避免后台线程扫描的时候进行全局加锁。

直接通过查询，判断其是否满足刷新条件，进行刷新。

Guava Cache 缓存回收

Guava Cache 提供了三种基本的缓存回收方式。

基于容量回收

maximumSize(long)：当缓存中的元素数量超过指定值时触发回收。

基于定时回收

• expireAfterAccess(long, TimeUnit)：缓存项在给定时间内没有被读/写访问，则回收。请注意这种缓存的回收顺序和基于大小回收一样。
• expireAfterWrite(long, TimeUnit)：缓存项在给定时间内没有被写访问（创建或覆盖），则回收。如果认为缓存数据总是在固定时候后变得陈旧不可用，这种回收方式是可取的。

如下文所讨论，定时回收周期性地在写操作中执行，偶尔在读操作中执行。

基于引用回收

• CacheBuilder.weakKeys()：使用弱引用存储键。当键没有其它（强或软）引用时，缓存项可以被垃圾回收。
• CacheBuilder.weakValues()：使用弱引用存储值。当值没有其它（强或软）引用时，缓存项可以被垃圾回收。
• CacheBuilder.softValues()：使用软引用存储值。软引用只有在响应内存需要时，才按照全局最近最少使用的顺序回收。

Guava Cache 核心 API

CacheBuilder

缓存构建器。构建缓存的入口，指定缓存配置参数并初始化本地缓存。
主要采用 builder 的模式，CacheBuilder 的每一个方法都返回这个 CacheBuilder 知道 build 方法的调用。
注意 build 方法有重载，带有参数的为构建一个具有数据加载功能的缓存，不带参数的构建一个没有数据加载功能的缓存。

LocalManualCache

作为 LocalCache 的一个内部类，在构造方法里面会把 LocalCache 类型的变量传入，并且调用方法时都直接或者间接调用 LocalCache 里面的方法。

LocalLoadingCache

可以看到该类继承了 LocalManualCache 并实现接口 LoadingCache。
覆盖了 get，getUnchecked 等方法。

LocalCache

Guava Cache 中的核心类，重点了解。

LocalCache 的数据结构与 ConcurrentHashMap 很相似，都由多个 segment 组成，且各 segment 相对独立，互不影响，所以能支持并行操作。每个 segment 由一个 table 和若干队列组成。缓存数据存储在 table 中，其类型为 AtomicReferenceArray。

四、Caffeine

caffeine 是一个使用 JDK8 改进 Guava 缓存的高性能缓存库。

Caffeine 实现了 W-TinyLFU(LFU + LRU 算法的变种)，其命中率和读写吞吐量大大优于 Guava Cache。

其实现原理较复杂，可以参考你应该知道的缓存进化史。

五、Ehcache

参考：Ehcache

六、进程内缓存对比

常用进程内缓存技术对比：

• ConcurrentHashMap - 比较适合缓存比较固定不变的元素，且缓存的数量较小的。虽然从上面表格中比起来有点逊色，但是其由于是 JDK 自带的类，在各种框架中依然有大量的使用，比如我们可以用来缓存我们反射的 Method，Field 等等；也可以缓存一些链接，防止其重复建立。在 Caffeine 中也是使用的 ConcurrentHashMap 来存储元素。
• LRUMap - 如果不想引入第三方包，又想使用淘汰算法淘汰数据，可以使用这个。
• Ehcache - 由于其 jar 包很大，较重量级。对于需要持久化和集群的一些功能的，可以选择 Ehcache。需要注意的是，虽然 Ehcache 也支持分布式缓存，但是由于其节点间通信方式为 rmi，表现不如 Redis，所以一般不建议用它来作为分布式缓存。
• Guava Cache - Guava 这个 jar 包在很多 Java 应用程序中都有大量的引入，所以很多时候其实是直接用就好了，并且其本身是轻量级的而且功能较为丰富，在不了解 Caffeine 的情况下可以选择 Guava Cache。
• Caffeine - 其在命中率，读写性能上都比 Guava Cache 好很多，并且其 API 和 Guava cache 基本一致，甚至会多一点。在真实环境中使用 Caffeine，取得过不错的效果。

总结一下：**如果不需要淘汰算法则选择 ConcurrentHashMap，如果需要淘汰算法和一些丰富的 API，推荐选择 Caffeine**。

参考资料

• caffeine github
• 深入解密来自未来的缓存-Caffeine
• Caffeine 缓存
• Google Guava 官方教程（中文版）
• Google Guava Cache 全解析
• 注释驱动的 Spring cache 缓存介绍

Http 缓存

HTTP 缓存分为 2 种，一种是强缓存，另一种是协商缓存。主要作用是可以加快资源获取速度，提升用户体验，减少网络传输，缓解服务端的压力。

Http 强缓存

不需要发送请求到服务端，直接读取浏览器本地缓存，在 Chrome 的 Network 中显示的 HTTP 状态码是 200 ，在 Chrome 中，强缓存又分为 Disk Cache (存放在硬盘中)和 Memory Cache (存放在内存中)，存放的位置是由浏览器控制的。是否强缓存由 Expires、Cache-Control 和 Pragma 3 个 Header 属性共同来控制。

Expires

Expires 的值是一个 HTTP 日期，在浏览器发起请求时，会根据系统时间和 Expires 的值进行比较，如果系统时间超过了 Expires 的值，缓存失效。由于和系统时间进行比较，所以当系统时间和服务器时间不一致的时候，会有缓存有效期不准的问题。Expires 的优先级在三个 Header 属性中是最低的。

Cache-Control

Cache-Control 是 HTTP/1.1 中新增的属性，在请求头和响应头中都可以使用，常用的属性值如有：

• max-age：单位是秒，缓存时间计算的方式是距离发起的时间的秒数，超过间隔的秒数缓存失效
• no-cache：不使用强缓存，需要与服务器验证缓存是否新鲜
• no-store：禁止使用缓存（包括协商缓存），每次都向服务器请求最新的资源
• private：专用于个人的缓存，中间代理、CDN 等不能缓存此响应
• public：响应可以被中间代理、CDN 等缓存
• must-revalidate：在缓存过期前可以使用，过期后必须向服务器验证

Pragma

Pragma 只有一个属性值，就是 no-cache ，效果和 Cache-Control 中的 no-cache 一致，不使用强缓存，需要与服务器验证缓存是否新鲜，在 3 个头部属性中的优先级最高。

协商缓存

当浏览器的强缓存失效的时候或者请求头中设置了不走强缓存，并且在请求头中设置了 If-Modified-Since 或者 If-None-Match 的时候，会将这两个属性值到服务端去验证是否命中协商缓存，如果命中了协商缓存，会返回 304 状态，加载浏览器缓存，并且响应头会设置 Last-Modified 或者 ETag 属性。

ETag/If-None-Match

Etag： 服务器响应请求时，通过此字段告诉浏览器当前资源在服务器生成的唯一标识（生成规则由服务器决定）

If-None-Match： 再次请求服务器时，浏览器的请求报文头部会包含此字段，后面的值为在缓存中获取的标识。服务器接收到次报文后发现 If-None-Match 则与被请求资源的唯一标识进行对比。

1. 不同，说明资源被改动过，则响应整个资源内容，返回状态码 200。
2. 相同，说明资源无心修改，则响应 header，浏览器直接从缓存中获取数据信息。返回状态码 304.

但是实际应用中由于 Etag 的计算是使用算法来得出的，而算法会占用服务端计算的资源，所有服务端的资源都是宝贵的，所以就很少使用 Etag 了。

Last-Modified/If-Modified-Since

Last-Modified： 服务器在响应请求时，会告诉浏览器资源的最后修改时间。

if-Modified-Since: 浏览器再次请求服务器的时候，请求头会包含此字段，后面跟着在缓存中获得的最后修改时间。服务端收到此请求头发现有 if-Modified-Since，则与被请求资源的最后修改时间进行对比，如果一致则返回 304 和响应报文头，浏览器只需要从缓存中获取信息即可。 从字面上看，就是说：从某个时间节点算起，是否文件被修改了

1. 如果真的被修改：那么开始传输响应一个整体，服务器返回：200 OK
2. 如果没有被修改：那么只需传输响应 header，服务器返回：304 Not Modified

if-Unmodified-Since: 从字面上看, 就是说: 从某个时间点算起, 是否文件没有被修改

1. 如果没有被修改:则开始`继续’传送文件: 服务器返回: 200 OK
2. 如果文件被修改:则不传输,服务器返回: 412 Precondition failed (预处理错误)

这两个的区别是一个是修改了才下载一个是没修改才下载。 Last-Modified 说好却也不是特别好，因为如果在服务器上，一个资源被修改了，但其实际内容根本没发生改变，会因为 Last-Modified 时间匹配不上而返回了整个实体给客户端（即使客户端缓存里有个一模一样的资源）。为了解决这个问题，HTTP1.1 推出了 Etag。

参考资料

• 图解 HTTP 缓存
• HTTP—-HTTP 缓存机制
• 缓存详解

Hystrix 快速入门

一、Hystrix 简介

Hystrix 是什么

Hystrix 是 Netflix 开源的一款容错框架，包含常用的容错方法：线程池隔离、信号量隔离、熔断、降级。

Hystrix 官方宣布不再发布新版本。

但是 Hystrix 的客户端熔断保护，断路器设计理念，有非常高的学习价值。

为什么需要 Hystrix

复杂的分布式系统架构中的应用程序往往具有数十个依赖项，每个依赖项都会不可避免地在某个时刻失败。 如果主机应用程序未与这些外部故障隔离开来，则可能会被波及。

例如，对于依赖于 30 个服务的应用程序，假设每个服务的正常运行时间为 99.99％，则可以期望：

99.99³⁰ = 99.7％ 的正常运行时间

10 亿个请求中的 0.3％= 3,000,000 个失败

即使所有依赖项都具有出色的正常运行时间，每月也会有 2 个小时以上的停机时间。

然而，现实情况一般比这种估量情况更糟糕。

当一切正常时，整体系统如下所示：

在高并发场景，这些依赖的稳定性与否对系统的影响非常大，但是依赖有很多不可控问题：如网络连接、资源繁忙、服务宕机等。例如：下图中有一个 QPS 为 50 的依赖 I 出现不可用，但是其他依赖服务是可用的。

但是，在高并发场景下，当依赖 I 阻塞时，大多数服务器的线程池就出现阻塞(BLOCK)。当这种级联故障愈演愈烈，就可能造成整个线上服务不可用的雪崩效应，如下图：

Hystrix 就是为了解决这类问题而应运而生。

Hystrix 的功能

Hystrix 具有以下功能：

• 避免资源耗尽：阻止任何一个依赖服务耗尽所有的资源，比如 tomcat 中的所有线程资源。
• 避免请求排队和积压：采用限流和 fail fast 来控制故障。
• 支持降级：提供 fallback 降级机制来应对故障。
• 资源隔离：比如 bulkhead（舱壁隔离技术）、swimlane（泳道技术）、circuit breaker（断路技术）来限制任何一个依赖服务的故障的影响。
• 统计/监控/报警：通过近实时的统计/监控/报警功能，来提高故障发现的速度。
• 通过近实时的属性和配置热修改功能，来提高故障处理和恢复的速度。
• 保护依赖服务调用的所有故障情况，而不仅仅只是网络故障情况。

如果使用 Hystrix 对每个基础依赖服务进行过载保护，则整个系统架构将会类似下图所示，每个依赖项彼此隔离，受到延迟时发生饱和的资源的被限制访问，并包含 fallback 逻辑（用于降级处理），该逻辑决定了在依赖项中发生任何类型的故障时做出对应的处理。

Hystrix 核心概念

二、Hystrix 工作流程

如下图所示，Hystrix 的工作流程大致可以分为 9 个步骤。

（一）包装命令

x 支持资源隔离。

资源隔离，就是说，你如果要把对某一个依赖服务的所有调用请求，全部隔离在同一份资源池内，不会去用其它资源了，这就叫资源隔离。哪怕对这个依赖服务，比如说商品服务，现在同时发起的调用量已经到了 1000，但是分配给商品服务线程池内就 10 个线程，最多就只会用这 10 个线程去执行。不会因为对商品服务调用的延迟，将 Tomcat 内部所有的线程资源全部耗尽。

Hystrix 进行资源隔离，其实是提供了一个抽象，叫做命令模式。这也是 Hystrix 最最基本的资源隔离技术。

在使用 Hystrix 的过程中，会对依赖服务的调用请求封装成命令对象，Hystrix 对 命令对象抽象了两个抽象类：HystrixCommand 和HystrixObservableCommand 。

• HystrixCommand 表示的命令对象会返回一个唯一返回值。
• HystrixObservableCommand 表示的命令对象 会返回多个返回值。

1
2

HystrixCommand command = new HystrixCommand(arg1, arg2);
HystrixObservableCommand command = new HystrixObservableCommand(arg1, arg2);

（二）执行命令

Hystrix 中共有 4 种方式执行命令，如下所示：

这四种命令中，exeucte()、queue()、observe()的表示也是通过toObservable()实现的，其转换关系如下图所示：

HystrixCommand 执行方式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

K value   = command.execute();
// 等价语句：
K value = command.execute().queue().get();


Future<K> fValue  = command.queue();
//等价语句：
Future<K> fValue = command.toObservable().toBlocking().toFuture();


Observable<K> ohValue = command.observe(); //hot observable，立刻订阅，命令立刻执行
//等价语句：
Observable<K> ohValue = command.toObservable().subscribe(subject);

// 上述执行最终实现还是基于 toObservable()
Observable<K> ocValue = command.toObservable(); //cold observable，延后订阅，订阅发生后，执行才真正执行

（三）是否缓存

如果当前命令对象配置了允许从结果缓存中取返回结果，并且在结果缓存中已经缓存了请求结果，则缓存的请求结果会立刻通过 Observable 的格式返回。

（四）是否开启断路器

如果第三步没有缓存没有命中，则判断一下当前断路器的断路状态是否打开。如果断路器状态为打开状态，则 Hystrix 将不会执行此 Command 命令，直接执行步骤 8 调用 Fallback；

如果断路器状态是关闭，则执行 步骤 5 检查是否有足够的资源运行 Command 命令

（五）信号量、线程池是否拒绝

如果当前要执行的 Command 命令 先关连的线程池 和队列(或者信号量)资源已经满了，Hystrix 将不会运行 Command 命令，直接执行 步骤 8的 Fallback 降级处理；如果未满，表示有剩余的资源执行 Command 命令，则执行步骤 6

（六）construct() 或 run()

当经过步骤 5 判断，有足够的资源执行 Command 命令时，本步骤将调用 Command 命令运行方法，基于不同类型的 Command，有如下两种两种运行方式：

如果run() 或者construct()方法 的真实执行时间超过了 Command 设置的超时时间阈值, 则当前则执行线程（或者是独立的定时器线程）将会抛出TimeoutException。抛出超时异常 TimeoutException，后，将执行步骤 8的 Fallback 降级处理。即使run()或者construct()执行没有被取消或中断，最终能够处理返回结果，但在降级处理逻辑中，将会抛弃run()或construct()方法的返回结果，而返回 Fallback 降级处理结果。

注意事项
需要注意的是，Hystrix 无法强制 将正在运行的线程停止掉–Hystrix 能够做的最好的方式就是在 JVM 中抛出一个InterruptedException。如果 Hystrix 包装的工作不抛出中断异常InterruptedException, 则在 Hystrix 线程池中的线程将会继续执行，尽管调用的客户端已经接收到了TimeoutException。这种方式会使 Hystrix 的线程池处于饱和状态。大部分的 Java Http Client 开源库并不会解析 InterruptedException。所以确认 HTTP client 相关的连接和读/写相关的超时时间设置。
如果 Command 命令没有抛出任何异常，并且有返回结果，则 Hystrix 将会在做完日志记录和统计之后会将结果返回。 如果是通过run()方式运行，则返回一个Obserable对象，包含一个唯一值，并且发送一个onCompleted通知；如果是通过consturct()方式运行 ，则返回一个Observable对象。

（七）健康检查

Hystrix 会统计 Command 命令执行执行过程中的成功数、失败数、拒绝数和超时数,将这些信息记录到断路器(Circuit Breaker)中。断路器将上述统计按照时间窗的形式记录到一个定长数组中。断路器根据时间窗内的统计数据去判定请求什么时候可以被熔断，熔断后，在接下来一段恢复周期内，相同的请求过来后会直接被熔断。当再次校验，如果健康监测通过后，熔断开关将会被关闭。

（八）获取 Fallback

当以下场景出现后，Hystrix 将会尝试触发 Fallback:

• 步骤 6 Command 执行时抛出了任何异常；
• 步骤 4 断路器已经被打开
• 步骤 5 执行命令的线程池、队列或者信号量资源已满
• 命令执行的时间超过阈值

（九）返回结果

如果 Hystrix 命令对象执行成功，将会返回结果，或者以Observable形式包装的结果。根据步骤 2的 command 调用方式，返回的Observable 会按照如下图说是的转换关系进行返回：

• execute() — 用和 .queue() 相同的方式获取 Future，然后调用 Future 的 get() 以获取 Observable 的单个值。
• queue() —将 Observable 转换为 BlockingObservable，以便可以将其转换为 Future 并返回。
• watch() —订阅 Observable 并开始执行命令的流程； 返回一个 Observable，当订阅该 Observable 时，它会重新通知。
• toObservable() —返回不变的 Observable； 必须订阅它才能真正开始执行命令的流程。

三、断路器工作原理

1. 断路器时间窗内的请求数 是否超过了请求数断路器生效阈值circuitBreaker.requestVolumeThreshold,如果超过了阈值，则将会触发断路，断路状态为开启
   例如，如果当前阈值设置的是20,则当时间窗内统计的请求数共计 19 个，即使 19 个全部失败了，都不会触发断路器。
2. 并且请求错误率超过了请求错误率阈值errorThresholdPercentage
3. 如果两个都满足，则将断路器由关闭迁移到开启
4. 如果断路器开启，则后续的所有相同请求将会被断路掉；
5. 直到过了沉睡时间窗sleepWindowInMilliseconds后，再发起请求时，允许其通过（此时的状态为半开起状态）。如果请求失败了，则保持断路器状态为开启状态，并更新沉睡时间窗。如果请求成功了，则将断路器状态改为关闭状态；

核心的逻辑如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

@Override
                       public void onNext(HealthCounts hc) {
                           // check if we are past the statisticalWindowVolumeThreshold
                           if (hc.getTotalRequests() < properties.circuitBreakerRequestVolumeThreshold().get()) {
                               // we are not past the minimum volume threshold for the stat window,
                               // so no change to circuit status.
                               // if it was CLOSED, it stays CLOSED
                               // if it was half-open, we need to wait for a successful command execution
                               // if it was open, we need to wait for sleep window to elapse
                           } else {
                               if (hc.getErrorPercentage() < properties.circuitBreakerErrorThresholdPercentage().get()) {
                                   //we are not past the minimum error threshold for the stat window,
                                   // so no change to circuit status.
                                   // if it was CLOSED, it stays CLOSED
                                   // if it was half-open, we need to wait for a successful command execution
                                   // if it was open, we need to wait for sleep window to elapse
                               } else {
                                   // our failure rate is too high, we need to set the state to OPEN
                                   if (status.compareAndSet(Status.CLOSED, Status.OPEN)) {
                                       circuitOpened.set(System.currentTimeMillis());
                                   }
                               }
                           }
                       }

系统指标

Hystrix 对系统指标的统计是基于时间窗模式的：

时间窗：最近的一个时间区间内，比如前一小时到现在，那么时间窗的长度就是1小时；
桶：桶是在特定的时间窗内，等分的指标收集的统计集合；比如时间窗的长度为1小时，而桶的数量为10,那么每个桶在时间轴上依次排开，时间由远及近，每个桶统计的时间分片为 1h / 10 = 6 min 6 分钟。一个桶中，包含了成功数、失败数、超时数、拒绝数 四个指标。

在系统内，时间窗会随着系统的运行逐渐向前移动，而时间窗的长度和桶的数量是固定不变的，那么随着时间的移动，会出现较久的过期的桶被移除出去，新的桶被添加进来，如下图所示：

四、资源隔离技术

线程池隔离

如下图所示，由于计算机系统的基本执行单位就是线程，线程具备独立的执行能力，所以，为了做到资源保护，需要对系统的线程池进行划分，对于外部调用方

1

User Request

的请求，调用各个线程池的服务，各个线程池独立完成调用，然后将结果返回

1

调用方

。在调用服务的过程中，如果

1

服务提供方

执行时间过长，则

1

调用方

可以直接以超时的方式直接返回，快速失败。

线程池隔离的几点好处

1. 使用超时返回的机制，避免同步调用服务时，调用时间过长，无法释放，导致资源耗尽的情况
2. 服务方可以控制请求数量，请求过多，可以直接拒绝,达到快速失败的目的；
3. 请求排队，线程池可以维护执行队列，将请求压到队列中处理

举个例子，如下代码段，模拟了同步调用服务的过程：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

//服务提供方，执行服务的时候模拟2分钟的耗时
Callable<String> callableService  = ()->{
    long start = System.currentTimeMillis();
    while(System.currentTimeMillis()-start> 1000 * 60 *2){
       //模拟服务执行时间过长的情况
    }
    return "OK";
};

//模拟10个客户端调用服务
ExecutorService clients = Executors.newFixedThreadPool(10);
//模拟给10个客户端提交处理请求
for (int i = 0; i < 20; i++) {
    clients.execute(()->{
        //同步调用
        try {
            String result = callableService.call();
            System.out.println("当前客户端："+Thread.currentThread().getName()+"调用服务完成，得到结果："+result);
        } catch (Exception e) {
            e.printStackTrace();
        }
    });
}

在此环节中，客户端 clients必须等待服务方返回结果之后，才能接收新的请求。如果用吞吐量来衡量系统的话，会发现系统的处理能力比较低。为了提高相应时间，可以借助线程池的方式，设置超时时间，这样的话，客户端就不需要必须等待服务方返回，如果时间过长，可以提前返回,改造后的代码如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

//服务提供方，执行服务的时候模拟2分钟的耗时
       Callable<String> callableService  = ()->{
           long start = System.currentTimeMillis();
           while(System.currentTimeMillis()-start> 1000 * 60 *2){
              //模拟服务执行时间过长的情况
           }
           return "OK";
       };

       //创建线程池作为服务方
       ExecutorService executorService = Executors.newFixedThreadPool(30);


       //模拟10个客户端调用服务
       ExecutorService clients = Executors.newFixedThreadPool(10);
       for (int i = 0; i < 10; i++) {
           clients.execute(()->{
               //同步调用
                   //将请求提交给线程池执行，Callable 和 Runnable在某种意义上，也是Command对象
                   Future<String> future = executorService.submit(callableService::call);
                   //在指定的时间内获取结果，如果超时，调用方可以直接返回
                   try {
                       String result = future.get(1000, TimeUnit.SECONDS);
                       //客户端等待时间之后，快速返回
                       System.out.println("当前客户端："+Thread.currentThread().getName()+"调用服务完成，得到结果："+result);
                   }catch (TimeoutException timeoutException){
                       System.out.println("服务调用超时，返回处理");
                   } catch (InterruptedException e) {

                   } catch (ExecutionException e) {
                   }
           });
       }

如果我们将服务方的线程池设置为：

1
2
3
4

ThreadPoolExecutor executorService = new ThreadPoolExecutor(10,1000,TimeUnit.SECONDS,
new ArrayBlockingQueue<>(100),
new ThreadPoolExecutor.DiscardPolicy() // 提交请求过多时，可以丢弃请求，避免死等阻塞的情况。
)

线程池隔离模式的弊端

线程池隔离模式，会根据服务划分出独立的线程池，系统资源的线程并发数是有限的，当线程数过多，系统话费大量的 CPU 时间来做线程上下文切换的无用操作，反而降低系统性能；如果线程池隔离的过多，会导致真正用于接收用户请求的线程就相应地减少，系统吞吐量反而下降；
在实践上，应当对像远程方法调用，网络资源请求这种服务时间不太可控的场景下使用线程池隔离模式处理
如下图所示，是线程池隔离模式的三种场景：

信号量隔离

由于基于线程池隔离的模式占用系统线程池资源，Hystrix 还提供了另外一个隔离技术：基于信号量的隔离。

基于信号量的隔离方式非常地简单，其核心就是使用共用变量

1

semaphore

进行原子操作，控制线程的并发量，当并发量达到一定量级时，服务禁止调用。如下图所示：信号量本身不会消耗多余的线程资源，所以就非常轻量。

基于信号量隔离的利弊

利：基于信号量的隔离，利用 JVM 的原子性 CAS 操作，避免了资源锁的竞争，省去了线程池开销，效率非常高；
弊：本质上基于信号量的隔离是同步行为，所以无法做到超时熔断，所以服务方自身要控制住执行时间，避免超时。
应用场景：业务服务上，有并发上限限制时，可以考虑此方式 > Alibaba Sentinel开源框架，就是基于信号量的熔断和断路器框架。

五、Hystrix 应用

Spring Cloud + Hystrix

• Hystrix 配置无法动态调节生效。Hystrix 框架本身是使用的Archaius框架完成的配置加载和刷新，但是集成自 Spring Cloud 下，无法有效地根据实时监控结果，动态调整熔断和系统参数
• 线程池和 Command 之间的配置比较复杂,在 Spring Cloud 在做 feigin-hystrix 集成的时候，还有些 BUG，对 command 的默认配置没有处理好，导致所有 command 占用公共的 command 线程池，没有细粒度控制，还需要做框架适配调整

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

public interface SetterFactory {

  /**
   * Returns a hystrix setter appropriate for the given target and method
   */
  HystrixCommand.Setter create(Target<?> target, Method method);

  /**
   * Default behavior is to derive the group key from {@link Target#name()} and the command key from
   * {@link Feign#configKey(Class, Method)}.
   */
  final class Default implements SetterFactory {

    @Override
    public HystrixCommand.Setter create(Target<?> target, Method method) {
      String groupKey = target.name();
      String commandKey = Feign.configKey(target.type(), method);
      return HystrixCommand.Setter
          .withGroupKey(HystrixCommandGroupKey.Factory.asKey(groupKey))
          .andCommandKey(HystrixCommandKey.Factory.asKey(commandKey));
          //没有处理好default配置项的加载
    }
  }
}

Hystrix 配置

详细配置可以参考 Hystrix 官方配置手册，这里仅介绍比较核心的配置

执行配置

以下配置用于控制 HystrixCommand.run() 如何执行。

断路配置

以下配置用于控制 HystrixCircuitBreaker 的断路处理。

指标配置

以下配置用于从 HystrixCommand 和 HystrixObservableCommand 执行中捕获相关指标。

线程池配置

以下配置用于控制 Hystrix Command 执行所使用的线程池。

六、其他限流技术

• resilience4j
  Hystrix 虽然官方宣布不再维护，其推荐另外一个框架：resilience4j, 这个框架是是为 Java 8 和 函数式编程设计的一个轻量级的容错框架，该框架充分利用函数式编程的概念，为函数式接口、lamda表达式、方法引用高阶函数进行包装，(本质上是装饰者模式的概念)，通过包装实现断路、限流、重试、舱壁功能。
  这个框架整体而言比较轻量，没有控制台，不太好做系统级监控；

• Alibaba Sentinel

  1

  Sentinel

  是 阿里巴巴开源的轻量级的流量控制、熔断降级 Java 库，该库的核心是使用的是信号量隔离的方式做流量控制和熔断，其优点是其集成性和易用性，几乎能和当前主流的 Spring Cloud, dubbo ,grpc ,nacos, zookeeper 做集成，如下图所示：

  

  sentinel-features-overview-en.png

  1

  Sentinel

  的目标生态圈：

  

  1

  sentinel

  一个强大的功能，就是它有一个流控管理控制台，你可以实时地监控每个服务的流控情况，并且可以实时编辑各种流控、熔断规则，有效地保证了服务保护的及时性。下图是内部试用的 sentinel 控制台：

  另外，

  1

  sentinel

  还可以和

  1	ctrip apollo

  分布式配置系统进行集成，将流控规降级等各种规则先配置在 apollo 中，然后服务启动自动加载流控规则。

参考资料

• Hystrix Github
• Spring Cloud Hystrix 设计原理
• Hystrix 都停更了，我为什么还要学？

Tomcat 快速入门

🎁 版本说明

当前最新版本：Tomcat 8.5.24

环境要求：JDK7+

1. Tomcat 简介

1.1. Tomcat 是什么

Tomcat 是由 Apache 开发的一个 Servlet 容器，实现了对 Servlet 和 JSP 的支持，并提供了作为 Web 服务器的一些特有功能，如 Tomcat 管理和控制平台、安全域管理和 Tomcat 阀等。

由于 Tomcat 本身也内含了一个 HTTP 服务器，它也可以被视作一个单独的 Web 服务器。但是，不能将 Tomcat 和 Apache HTTP 服务器混淆，Apache HTTP 服务器是一个用 C 语言实现的 HTTP Web 服务器；这两个 HTTP web server 不是捆绑在一起的。Tomcat 包含了一个配置管理工具，也可以通过编辑 XML 格式的配置文件来进行配置。

1.2. Tomcat 重要目录

• /bin - Tomcat 脚本存放目录（如启动、关闭脚本）。 *.sh 文件用于 Unix 系统； *.bat 文件用于 Windows 系统。
• /conf - Tomcat 配置文件目录。
• /logs - Tomcat 默认日志目录。
• /webapps - webapp 运行的目录。

1.3. web 工程发布目录结构

一般 web 项目路径结构

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

|-- webapp                         # 站点根目录
    |-- META-INF                   # META-INF 目录
    |   `-- MANIFEST.MF            # 配置清单文件
    |-- WEB-INF                    # WEB-INF 目录
    |   |-- classes                # class文件目录
    |   |   |-- *.class            # 程序需要的 class 文件
    |   |   `-- *.xml              # 程序需要的 xml 文件
    |   |-- lib                    # 库文件夹
    |   |   `-- *.jar              # 程序需要的 jar 包
    |   `-- web.xml                # Web应用程序的部署描述文件
    |-- <userdir>                  # 自定义的目录
    |-- <userfiles>                # 自定义的资源文件

• webapp：工程发布文件夹。其实每个 war 包都可以视为 webapp 的压缩包。

• META-INF：META-INF 目录用于存放工程自身相关的一些信息，元文件信息，通常由开发工具，环境自动生成。

• WEB-INF：Java web 应用的安全目录。所谓安全就是客户端无法访问，只有服务端可以访问的目录。

• /WEB-INF/classes：存放程序所需要的所有 Java class 文件。

• /WEB-INF/lib：存放程序所需要的所有 jar 文件。

• /WEB-INF/web.xml：web 应用的部署配置文件。它是工程中最重要的配置文件，它描述了 servlet 和组成应用的其它组件，以及应用初始化参数、安全管理约束等。

1.4. Tomcat 功能

Tomcat 支持的 I/O 模型有：

• NIO：非阻塞 I/O，采用 Java NIO 类库实现。
• NIO2：异步 I/O，采用 JDK 7 最新的 NIO2 类库实现。
• APR：采用 Apache 可移植运行库实现，是 C/C++ 编写的本地库。

Tomcat 支持的应用层协议有：

• HTTP/1.1：这是大部分 Web 应用采用的访问协议。
• AJP：用于和 Web 服务器集成（如 Apache）。
• HTTP/2：HTTP 2.0 大幅度的提升了 Web 性能。

2. Tomcat 入门

2.1. 安装

前提条件

Tomcat 8.5 要求 JDK 版本为 1.7 以上。

进入 Tomcat 官方下载地址 选择合适版本下载，并解压到本地。

Windows

添加环境变量 CATALINA_HOME ，值为 Tomcat 的安装路径。

进入安装目录下的 bin 目录，运行 startup.bat 文件，启动 Tomcat

Linux / Unix

下面的示例以 8.5.24 版本为例，包含了下载、解压、启动操作。

1
2
3
4
5

# 下载解压到本地
wget http://mirrors.hust.edu.cn/apache/tomcat/tomcat-8/v8.5.24/bin/apache-tomcat-8.5.24.tar.gz
tar -zxf apache-tomcat-8.5.24.tar.gz
# 启动 Tomcat
./apache-tomcat-8.5.24/bin/startup.sh

启动后，访问 http://localhost:8080 ，可以看到 Tomcat 安装成功的测试页面。

2.2. 配置

本节将列举一些重要、常见的配置项。详细的 Tomcat8 配置可以参考 Tomcat 8 配置官方参考文档 。

2.2.1. Server

Server 元素表示整个 Catalina servlet 容器。

因此，它必须是 conf/server.xml 配置文件中的根元素。它的属性代表了整个 servlet 容器的特性。

属性表

2.2.2. Service

Service 元素表示一个或多个连接器组件的组合，这些组件共享一个用于处理传入请求的引擎组件。Server 中可以有多个 Service。

属性表

实例 - conf/server.xml 配置文件示例

1
2
3
4
5
6

<?xml version="1.0" encoding="UTF-8"?>
<Server port="8080" shutdown="SHUTDOWN">
  <Service name="xxx">
  ...
  </Service>
</Server>

2.2.3. Executor

Executor 表示可以在 Tomcat 中的组件之间共享的线程池。

属性表

1
2
3

<Service name="xxx">
  <Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="300" minSpareThreads="25"/>
</Service>

2.2.4. Connector

Connector 代表连接组件。Tomcat 支持三种协议：HTTP/1.1、HTTP/2.0、AJP。

属性表

以下属性在标准的 Connector(NIO, NIO2 和 APR/native)中有效:

2.2.5. Context

Context 元素表示一个 Web 应用程序，它在特定的虚拟主机中运行。每个 Web 应用程序都基于 Web 应用程序存档（WAR）文件，或者包含相应的解包内容的相应目录，如 Servlet 规范中所述。

属性表

2.2.6. Engine

Engine 元素表示与特定的 Catalina 服务相关联的整个请求处理机器。它接收并处理来自一个或多个连接器的所有请求，并将完成的响应返回给连接器，以便最终传输回客户端。

属性表

2.2.7. Host

Host 元素表示一个虚拟主机，它是一个服务器的网络名称（如“www.mycompany.com”）与运行 Tomcat 的特定服务器的关联。

属性表

2.2.8. Cluster

由于在实际开发中，我从未用过 Tomcat 集群配置，所以没研究。

2.3. 启动

2.3.1. 部署方式

这种方式要求本地必须安装 Tomcat 。

将打包好的 war 包放在 Tomcat 安装目录下的 webapps 目录下，然后在 bin 目录下执行 startup.bat 或 startup.sh ，Tomcat 会自动解压 webapps 目录下的 war 包。

成功后，可以访问 http://localhost:8080/xxx （xxx 是 war 包文件名）。

注意

以上步骤是最简单的示例。步骤中的 war 包解压路径、启动端口以及一些更多的功能都可以修改配置文件来定制 （主要是 server.xml 或 context.xml 文件）。

2.3.2. 嵌入式

2.3.2.1. API 方式

在 pom.xml 中添加依赖

1
2
3
4
5

<dependency>
  <groupId>org.apache.tomcat.embed</groupId>
  <artifactId>tomcat-embed-core</artifactId>
  <version>8.5.24</version>
</dependency>

添加 SimpleEmbedTomcatServer.java 文件，内容如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

import java.util.Optional;
import org.apache.catalina.startup.Tomcat;

public class SimpleTomcatServer {
    private static final int PORT = 8080;
    private static final String CONTEXT_PATH = "/javatool-server";

    public static void main(String[] args) throws Exception {
        // 设定 profile
        Optional<String> profile = Optional.ofNullable(System.getProperty("spring.profiles.active"));
        System.setProperty("spring.profiles.active", profile.orElse("develop"));

        Tomcat tomcat = new Tomcat();
        tomcat.setPort(PORT);
        tomcat.getHost().setAppBase(".");
        tomcat.addWebapp(CONTEXT_PATH, getAbsolutePath() + "src/main/webapp");
        tomcat.start();
        tomcat.getServer().await();
    }

    private static String getAbsolutePath() {
        String path = null;
        String folderPath = SimpleEmbedTomcatServer.class.getProtectionDomain().getCodeSource().getLocation().getPath()
                .substring(1);
        if (folderPath.indexOf("target") > 0) {
            path = folderPath.substring(0, folderPath.indexOf("target"));
        }
        return path;
    }
}

成功后，可以访问 http://localhost:8080/javatool-server 。

说明

本示例是使用 org.apache.tomcat.embed 启动嵌入式 Tomcat 的最简示例。

这个示例中使用的是 Tomcat 默认的配置，但通常，我们需要对 Tomcat 配置进行一些定制和调优。为了加载配置文件，启动类就要稍微再复杂一些。这里不想再贴代码，有兴趣的同学可以参考：

示例项目

2.3.2.2. 使用 maven 插件启动（不推荐）

不推荐理由：这种方式启动 maven 虽然最简单，但是有一个很大的问题是，真的很久很久没发布新版本了（最新版本发布时间：2013-11-11）。且貌似只能找到 Tomcat6 、Tomcat7 插件。

使用方法

在 pom.xml 中引入插件

1
2
3
4
5
6
7
8
9
10