JavaWeb 之 Cookie 和 Session

发表于 2020-08-24 更新于 2024-01-27 分类于 Java ， JavaEE ， JavaWeb 本文字数： 17k 阅读时长 ≈ 16 分钟

由于 Http 是一种无状态的协议，服务器单从网络连接上无从知道客户身份。

会话跟踪是 Web 程序中常用的技术，用来跟踪用户的整个会话。常用会话跟踪技术是 Cookie 与 Session。

Cookie 实际上是存储在客户端上的文本信息，并保留了各种跟踪的信息。

Cookie 工作步骤：

客户端请求服务器，如果服务器需要记录该用户的状态，就是用 response 向客户端浏览器颁发一个 Cookie。
客户端浏览器会把 Cookie 保存下来。
当浏览器再请求该网站时，浏览器把该请求的网址连同 Cookie 一同提交给服务器。服务器检查该 Cookie，以此来辨认用户状态。

注：Cookie 功能需要浏览器的支持，如果浏览器不支持 Cookie 或者 Cookie 禁用了，Cookie 功能就会失效。

Java 中把 Cookie 封装成了javax.servlet.http.Cookie类。

Cookies 通常设置在 HTTP 头信息中（虽然 JavaScript 也可以直接在浏览器上设置一个 Cookie）。

设置 Cookie 的 Servlet 会发送如下的头信息：

HTTP/1.1 200 OK
Date: Fri, 04 Feb 2000 21:03:38 GMT
Server: Apache/1.3.9 (UNIX) PHP/4.0b3
Set-Cookie: name=xyz; expires=Friday, 04-Feb-07 22:03:38 GMT;
                 path=/; domain=w3cschool.cc
Connection: close
Content-Type: text/html

正如您所看到的，Set-Cookie 头包含了一个名称值对、一个 GMT 日期、一个路径和一个域。名称和值会被 URL 编码。expires 字段是一个指令，告诉浏览器在给定的时间和日期之后”忘记”该 Cookie。

如果浏览器被配置为存储 Cookies，它将会保留此信息直到到期日期。如果用户的浏览器指向任何匹配该 Cookie 的路径和域的页面，它会重新发送 Cookie 到服务器。浏览器的头信息可能如下所示：

GET / HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/4.6 (X11; I; Linux 2.2.6-15apmac ppc)
Host: zink.demon.co.uk:1126
Accept: image/gif, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
Cookie: name=xyz

方法	功能
public void setDomain(String pattern)	该方法设置 cookie 适用的域。
public String getDomain()	该方法获取 cookie 适用的域。
public void setMaxAge(int expiry)	该方法设置 cookie 过期的时间（以秒为单位）。如果不这样设置，cookie 只会在当前 session 会话中持续有效。
public int getMaxAge()	该方法返回 cookie 的最大生存周期（以秒为单位），默认情况下，-1 表示 cookie 将持续下去，直到浏览器关闭。
public String getName()	该方法返回 cookie 的名称。名称在创建后不能改变。
public void setValue(String newValue)	该方法设置与 cookie 关联的值。
public String getValue()	该方法获取与 cookie 关联的值。
public void setPath(String uri)	该方法设置 cookie 适用的路径。如果您不指定路径，与当前页面相同目录下的（包括子目录下的）所有 URL 都会返回 cookie。
public String getPath()	该方法获取 cookie 适用的路径。
public void setSecure(boolean flag)	该方法设置布尔值，向浏览器指示，只会在 HTTPS 和 SSL 等安全协议中传输此类 Cookie。
public void setComment(String purpose)	该方法规定了描述 cookie 目的的注释。该注释在浏览器向用户呈现 cookie 时非常有用。
public String getComment()	该方法返回了描述 cookie 目的的注释，如果 cookie 没有注释则返回 null。

Cookie的maxAge决定着 Cookie 的有效期，单位为秒。

如果 maxAge 为 0，则表示删除该 Cookie；

如果为负数，表示该 Cookie 仅在本浏览器中以及本窗口打开的子窗口内有效，关闭窗口后该 Cookie 即失效。

Cookie 中提供getMaxAge()和setMaxAge(int expiry)方法来读写maxAge属性。

Cookie 是不可以跨域名的。域名 www.google.com 颁发的 Cookie 不会被提交到域名 www.baidu.com 去。这是由 Cookie 的隐私安全机制决定的。隐私安全机制能够禁止网站非法获取其他网站的 Cookie。

正常情况下，同一个一级域名的两个二级域名之间也不能互相使用 Cookie。如果想让某域名下的子域名也可以使用该 Cookie，需要设置 Cookie 的 domain 参数。

Java 中使用setDomain(Stringdomain)和getDomain()方法来设置、获取 domain。

Path 属性决定允许访问 Cookie 的路径。

Java 中使用setPath(Stringuri)和getPath()方法来设置、获取 path。

HTTP 协议不仅是无状态的，而且是不安全的。

使用 HTTP 协议的数据不经过任何加密就直接在网络上传播，有被截获的可能。如果不希望 Cookie 在 HTTP 等非安全协议中传输，可以设置 Cookie 的 secure 属性为 true。浏览器只会在 HTTPS 和 SSL 等安全协议中传输此类 Cookie。

Java 中使用setSecure(booleanflag)和getSecure ()方法来设置、获取 Secure。

通过 Servlet 添加 Cookies 包括三个步骤：

创建一个 Cookie 对象：您可以调用带有 cookie 名称和 cookie 值的 Cookie 构造函数，cookie 名称和 cookie 值都是字符串。
设置最大生存周期：您可以使用 setMaxAge 方法来指定 cookie 能够保持有效的时间（以秒为单位）。
发送 Cookie 到 HTTP 响应头：您可以使用 response.addCookie 来添加 HTTP 响应头中的 Cookies。

AddCookies.java

import java.io.IOException;
import java.io.PrintWriter;
import java.net.URLEncoder;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@WebServlet("/servlet/AddCookies")
public class AddCookies extends HttpServlet {
    private static final long serialVersionUID = 1L;

    /**
     * @see HttpServlet#HttpServlet()
     */
    public AddCookies() {
        super();
    }

    /**
     * @see HttpServlet#doGet(HttpServletRequest request, HttpServletResponse response)
     */
    public void doGet(HttpServletRequest request, HttpServletResponse response)
                    throws ServletException, IOException {
        // 为名字和姓氏创建 Cookie
        Cookie name = new Cookie("name", URLEncoder.encode(request.getParameter("name"), "UTF-8")); // 中文转码
        Cookie url = new Cookie("url", request.getParameter("url"));

        // 为两个 Cookie 设置过期日期为 24 小时后
        name.setMaxAge(60 * 60 * 24);
        url.setMaxAge(60 * 60 * 24);

        // 在响应头中添加两个 Cookie
        response.addCookie(name);
        response.addCookie(url);

        // 设置响应内容类型
        response.setContentType("text/html;charset=UTF-8");

        PrintWriter out = response.getWriter();
        String title = "设置 Cookie 实例";
        String docType = "<!DOCTYPE html>\n";
        out.println(docType + "<html>\n" + "<head><title>" + title + "</title></head>\n"
                        + "<body bgcolor=\"#f0f0f0\">\n" + "<h1 align=\"center\">" + title
                        + "</h1>\n" + "<ul>\n" + "  <li><b>站点名：</b>：" + request.getParameter("name")
                        + "\n</li>" + "  <li><b>站点 URL：</b>：" + request.getParameter("url")
                        + "\n</li>" + "</ul>\n" + "</body></html>");
    }

    /**
     * @see HttpServlet#doPost(HttpServletRequest request, HttpServletResponse response)
     */
    protected void doPost(HttpServletRequest request, HttpServletResponse response)
                    throws ServletException, IOException {
        doGet(request, response);
    }

}

addCookies.jsp

<%@ page language="java" pageEncoding="UTF-8" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta charset="utf-8">
  <title>添加Cookie</title>
</head>
<body>
<form action=/servlet/AddCookies method="GET">
  站点名 ：<input type="text" name="name">
  <br/>
  站点 URL：<input type="text" name="url"/><br>
  <input type="submit" value="提交"/>
</form>
</body>
</html>

要读取 Cookies，您需要通过调用 HttpServletRequest 的 getCookies() 方法创建一个 javax.servlet.http.Cookie 对象的数组。然后循环遍历数组，并使用 getName() 和 getValue() 方法来访问每个 cookie 和关联的值。

ReadCookies.java

import java.io.IOException;
import java.io.PrintWriter;
import java.net.URLDecoder;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@WebServlet("/servlet/ReadCookies")
public class ReadCookies extends HttpServlet {
    private static final long serialVersionUID = 1L;

    /**
     * @see HttpServlet#HttpServlet()
     */
    public ReadCookies() {
        super();
    }

    /**
     * @see HttpServlet#doGet(HttpServletRequest request, HttpServletResponse response)
     */
    public void doGet(HttpServletRequest request, HttpServletResponse response)
                    throws ServletException, IOException {
        Cookie cookie = null;
        Cookie[] cookies = null;
        // 获取与该域相关的 Cookie 的数组
        cookies = request.getCookies();

        // 设置响应内容类型
        response.setContentType("text/html;charset=UTF-8");

        PrintWriter out = response.getWriter();
        String title = "Delete Cookie Example";
        String docType = "<!DOCTYPE html>\n";
        out.println(docType + "<html>\n" + "<head><title>" + title + "</title></head>\n"
                        + "<body bgcolor=\"#f0f0f0\">\n");
        if (cookies != null) {
            out.println("<h2>Cookie 名称和值</h2>");
            for (int i = 0; i < cookies.length; i++) {
                cookie = cookies[i];
                if ((cookie.getName()).compareTo("name") == 0) {
                    cookie.setMaxAge(0);
                    response.addCookie(cookie);
                    out.print("已删除的 cookie：" + cookie.getName() + "<br/>");
                }
                out.print("名称：" + cookie.getName() + "，");
                out.print("值：" + URLDecoder.decode(cookie.getValue(), "utf-8") + " <br/>");
            }
        } else {
            out.println("<h2 class=\"tutheader\">No Cookie founds</h2>");
        }
        out.println("</body>");
        out.println("</html>");
    }

    /**
     * @see HttpServlet#doPost(HttpServletRequest request, HttpServletResponse response)
     */
    protected void doPost(HttpServletRequest request, HttpServletResponse response)
                    throws ServletException, IOException {
        doGet(request, response);
    }

}

Java 中并没有提供直接删除 Cookie 的方法，如果想要删除一个 Cookie，直接将这个 Cookie 的有效期设为 0 就可以了。步骤如下：

读取一个现有的 cookie，并把它存储在 Cookie 对象中。
使用 setMaxAge() 方法设置 cookie 的年龄为零，来删除现有的 cookie。
把这个 cookie 添加到响应头。

DeleteCookies.java

import java.io.IOException;
import java.io.PrintWriter;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@WebServlet("/servlet/DeleteCookies")
public class DeleteCookies extends HttpServlet {
    private static final long serialVersionUID = 1L;

    /**
     * @see HttpServlet#HttpServlet()
     */
    public DeleteCookies() {
        super();
    }

    /**
     * @see HttpServlet#doGet(HttpServletRequest request, HttpServletResponse response)
     */
    public void doGet(HttpServletRequest request, HttpServletResponse response)
                    throws ServletException, IOException {
        Cookie cookie = null;
        Cookie[] cookies = null;
        // 获取与该域相关的 Cookie 的数组
        cookies = request.getCookies();

        // 设置响应内容类型
        response.setContentType("text/html;charset=UTF-8");

        PrintWriter out = response.getWriter();
        String title = "删除 Cookie 实例";
        String docType = "<!DOCTYPE html>\n";
        out.println(docType + "<html>\n" + "<head><title>" + title + "</title></head>\n"
                        + "<body bgcolor=\"#f0f0f0\">\n");
        if (cookies != null) {
            out.println("<h2>Cookie 名称和值</h2>");
            for (int i = 0; i < cookies.length; i++) {
                cookie = cookies[i];
                if ((cookie.getName()).compareTo("url") == 0) {
                    cookie.setMaxAge(0);
                    response.addCookie(cookie);
                    out.print("已删除的 cookie：" + cookie.getName() + "<br/>");
                }
                out.print("名称：" + cookie.getName() + "，");
                out.print("值：" + cookie.getValue() + " <br/>");
            }
        } else {
            out.println("<h2 class=\"tutheader\">No Cookie founds</h2>");
        }
        out.println("</body>");
        out.println("</html>");
    }

    /**
     * @see HttpServlet#doPost(HttpServletRequest request, HttpServletResponse response)
     */
    protected void doPost(HttpServletRequest request, HttpServletResponse response)
                    throws ServletException, IOException {
        doGet(request, response);
    }

}

Session

Session 是什么

不同于 Cookie 保存在客户端浏览器中，Session 保存在服务器上。

如果说 Cookie 机制是通过检查客户身上的“通行证”来确定客户身份的话，那么 Session 机制就是通过检查服务器上的“客户明细表”来确认客户身份。

Session 对应的类为 javax.servlet.http.HttpSession 类。Session 对象是在客户第一次请求服务器时创建的。

Session 类中的方法

javax.servlet.http.HttpSession 类中的方法：

方法	功能
public Object getAttribute(String name)	该方法返回在该 session 会话中具有指定名称的对象，如果没有指定名称的对象，则返回 null。
public Enumeration getAttributeNames()	该方法返回 String 对象的枚举，String 对象包含所有绑定到该 session 会话的对象的名称。
public long getCreationTime()	该方法返回该 session 会话被创建的时间，自格林尼治标准时间 1970 年 1 月 1 日午夜算起，以毫秒为单位。
public String getId()	该方法返回一个包含分配给该 session 会话的唯一标识符的字符串。
public long getLastAccessedTime()	该方法返回客户端最后一次发送与该 session 会话相关的请求的时间自格林尼治标准时间 1970 年 1 月 1 日午夜算起，以毫秒为单位。
public int getMaxInactiveInterval()	该方法返回 Servlet 容器在客户端访问时保持 session 会话打开的最大时间间隔，以秒为单位。
public void invalidate()	该方法指示该 session 会话无效，并解除绑定到它上面的任何对象。
public boolean isNew()	如果客户端还不知道该 session 会话，或者如果客户选择不参入该 session 会话，则该方法返回 true。
public void removeAttribute(String name)	该方法将从该 session 会话移除指定名称的对象。
public void setAttribute(String name, Object value)	该方法使用指定的名称绑定一个对象到该 session 会话。
public void setMaxInactiveInterval(int interval)	该方法在 Servlet 容器指示该 session 会话无效之前，指定客户端请求之间的时间，以秒为单位。

Session 的有效期

由于会有越来越多的用户访问服务器，因此 Session 也会越来越多。为防止内存溢出，服务器会把长时间没有活跃的 Session 从内存中删除。

Session 的超时时间为maxInactiveInterval属性，可以通过getMaxInactiveInterval()、setMaxInactiveInterval(longinterval)来读写这个属性。

Tomcat 中 Session 的默认超时时间为 20 分钟。可以修改 web.xml 改变 Session 的默认超时时间。

例：

1
2
3

<session-config>
  <session-timeout>60</session-timeout>
</session-config>

Session 对浏览器的要求

HTTP 协议是无状态的，Session 不能依据 HTTP 连接来判断是否为同一客户。因此服务器向客户端浏览器发送一个名为 JESSIONID 的 Cookie，他的值为该 Session 的 id（也就是 HttpSession.getId()的返回值）。Session 依据该 Cookie 来识别是否为同一用户。

该 Cookie 为服务器自动生成的，它的maxAge属性一般为-1，表示仅当前浏览器内有效，并且各浏览器窗口间不共享，关闭浏览器就会失效。

URL 地址重写

URL 地址重写的原理是将该用户 Session 的 id 信息重写到 URL 地址中。服务器能够解析重写后的 URL 获取 Session 的 id。这样即使客户端不支持 Cookie，也可以使用 Session 来记录用户状态。

HttpServletResponse类提供了encodeURL(Stringurl)实现 URL 地址重写。

在META-INF/context.xml中编辑如下：

1 2	<Context path="/SessionNotes" cookies="true"> </Context>

部署后，TOMCAT 便不会自动生成名 JESSIONID 的 Cookie，Session 也不会以 Cookie 为识别标志，而仅仅以重写后的 URL 地址为识别标志了。

Session 实例

Session 跟踪

SessionTrackServlet.java

import java.io.IOException;
import java.io.PrintWriter;
import java.text.SimpleDateFormat;
import java.util.Date;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;

@WebServlet("/servlet/SessionTrackServlet")
public class SessionTrackServlet extends HttpServlet {
    private static final long serialVersionUID = 1L;

    public void doGet(HttpServletRequest request, HttpServletResponse response)
                    throws ServletException, IOException {
        // 如果不存在 session 会话，则创建一个 session 对象
        HttpSession session = request.getSession(true);
        // 获取 session 创建时间
        Date createTime = new Date(session.getCreationTime());
        // 获取该网页的最后一次访问时间
        Date lastAccessTime = new Date(session.getLastAccessedTime());

        // 设置日期输出的格式
        SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

        String title = "Servlet Session 实例";
        Integer visitCount = new Integer(0);
        String visitCountKey = new String("visitCount");
        String userIDKey = new String("userID");
        String userID = new String("admin");

        // 检查网页上是否有新的访问者
        if (session.isNew()) {
            session.setAttribute(userIDKey, userID);
        } else {
            visitCount = (Integer) session.getAttribute(visitCountKey);
            visitCount = visitCount + 1;
            userID = (String) session.getAttribute(userIDKey);
        }
        session.setAttribute(visitCountKey, visitCount);

        // 设置响应内容类型
        response.setContentType("text/html;charset=UTF-8");
        PrintWriter out = response.getWriter();

        String docType = "<!DOCTYPE html>\n";
        out.println(docType + "<html>\n" + "<head><title>" + title + "</title></head>\n"
                        + "<body bgcolor=\"#f0f0f0\">\n" + "<h1 align=\"center\">" + title
                        + "</h1>\n" + "<h2 align=\"center\">Session 信息</h2>\n"
                        + "<table border=\"1\" align=\"center\">\n" + "<tr bgcolor=\"#949494\">\n"
                        + "  <th>Session 信息</th><th>值</th></tr>\n" + "<tr>\n" + "  <td>id</td>\n"
                        + "  <td>" + session.getId() + "</td></tr>\n" + "<tr>\n"
                        + "  <td>创建时间</td>\n" + "  <td>" + df.format(createTime) + "  </td></tr>\n"
                        + "<tr>\n" + "  <td>最后访问时间</td>\n" + "  <td>" + df.format(lastAccessTime)
                        + "  </td></tr>\n" + "<tr>\n" + "  <td>用户 ID</td>\n" + "  <td>" + userID
                        + "  </td></tr>\n" + "<tr>\n" + "  <td>访问统计：</td>\n" + "  <td>" + visitCount
                        + "</td></tr>\n" + "</table>\n" + "</body></html>");
    }
}

web.xml

<servlet>
  <servlet-name>SessionTrackServlet</servlet-name>
  <servlet-class>SessionTrackServlet</servlet-class>
</servlet>
<servlet-mapping>
  <servlet-name>SessionTrackServlet</servlet-name>
  <url-pattern>/servlet/SessionTrackServlet</url-pattern>
</servlet-mapping>

删除 Session 会话数据

当您完成了一个用户的 session 会话数据，您有以下几种选择：

移除一个特定的属性：您可以调用 removeAttribute(String name) 方法来删除与特定的键相关联的值。

删除整个 session 会话：您可以调用 invalidate() 方法来丢弃整个 session 会话。

设置 session 会话过期时间：您可以调用 setMaxInactiveInterval(int interval) 方法来单独设置 session 会话超时。

注销用户：如果使用的是支持 servlet 2.4 的服务器，您可以调用 logout 来注销 Web 服务器的客户端，并把属于所有用户的所有 session 会话设置为无效。

web.xml 配置：如果您使用的是 Tomcat，除了上述方法，您还可以在 web.xml 文件中配置 session 会话超时，如下所示：

1
2
3

<session-config>
  <session-timeout>15</session-timeout>
</session-config>

上面实例中的超时时间是以分钟为单位，将覆盖 Tomcat 中默认的 30 分钟超时时间。

在一个 Servlet 中的 getMaxInactiveInterval() 方法会返回 session 会话的超时时间，以秒为单位。所以，如果在 web.xml 中配置 session 会话超时时间为 15 分钟，那么getMaxInactiveInterval() 会返回 900。

存取方式

Cookie 只能保存ASCII字符串，如果需要存取 Unicode 字符或二进制数据，需要进行UTF-8、GBK或BASE64等方式的编码。

Session 可以存取任何类型的数据，甚至是任何 Java 类。可以将 Session 看成是一个 Java 容器类。

隐私安全

Cookie 存于客户端浏览器，一些客户端的程序可能会窥探、复制或修改 Cookie 内容。

Session 存于服务器，对客户端是透明的，不存在敏感信息泄露的危险。

有效期

使用 Cookie 可以保证长时间登录有效，只要设置 Cookie 的maxAge属性为一个很大的数字。

而 Session 虽然理论上也可以通过设置很大的数值来保持长时间登录有效，但是，由于 Session 依赖于名为JESSIONID的 Cookie，而 Cookie JESSIONID的maxAge默认为-1，只要关闭了浏览器该 Session 就会失效，因此，Session 不能实现信息永久有效的效果。使用 URL 地址重写也不能实现。

服务器的开销

由于 Session 是保存在服务器的，每个用户都会产生一个 Session，如果并发访问的用户非常多，会产生很多的 Session，消耗大量的内存。

而 Cookie 由于保存在客户端浏览器上，所以不占用服务器资源。

浏览器的支持

Cookie 需要浏览器支持才能使用。

如果浏览器不支持 Cookie，需要使用 Session 以及 URL 地址重写。

需要注意的事所有的用到 Session 程序的 URL 都要使用response.encodeURL(StringURL) 或response.encodeRediretURL(String URL)进行 URL 地址重写，否则导致 Session 会话跟踪失效。

跨域名

Cookie 支持跨域名。
Session 不支持跨域名。

错误处理

发表于 2020-08-13 更新于 2024-01-27 分类于编程，编程范式本文字数： 5.8k 阅读时长 ≈ 5 分钟

错误处理

错误的分类

资源的错误

当我们的代码去请求一些资源时导致的错误，比如打开一个没有权限的文件，写文件时出现的写错误，发送文件到网络端发现网络故障的错误，等等。这一类错误属于程序运行环境的问题。对于这类错误，有的我们可以处理，有的我们则无法处理。比如，内存耗尽、栈溢出或是一些程序运行时关键性资源不能满足等等这些情况，我们只能停止运行，甚至退出整个程序。

程序的错误

比如：空指针、非法参数等。这类是我们自己程序的错误，我们要记录下来，写入日志，最好触发监控系统报警。

用户的错误

比如：Bad Request、Bad Format 等这类由用户不合法输入带来的错误。这类错误基本上是在用户的 API 层上出现的问题。比如，解析一个 XML 或 JSON 文件，或是用户输入的字段不合法之类的。

对于这类问题，我们需要向用户端报错，让用户自己处理修正他们的输入或操作。然后，我们正常执行，但是需要做统计，统计相应的错误率，这样有利于我们改善软件或是侦测是否有恶意的用户请求。

错误返回码和异常捕捉

错误处理一般有两种方式：错误返回码和异常捕捉。

对于我们并不期望会发生的事，我们可以使用异常捕捉；
对于我们觉得可能会发生的事，使用返回码。

异步编程的错误处理

无法使用返回码。因为函数在“被”异步运行中，所谓的返回只是把处理权交给下一条指令，而不是把函数运行完的结果返回。所以，函数返回的语义完全变了，返回码也没有用了。
无法使用抛异常的方式。因为除了上述的函数立马返回的原因之外，抛出的异常也在另外一个线程中，不同线程中的栈是完全不一样的，所以主线程的 catch 完全看不到另外一个线程中的异常。

callback 错误处理

异步编程中，最常用的错误处理方式就是 callback 方式。在做异步请求的时候，注册几个 OnSuccess()、 OnFailure() 这样的函数，让在另一个线程中运行的异步代码来回调过来。

【示例】JavaScript 异步编程的错误处理

function successCallback(result) {
  console.log('It succeeded with ' + result)
}

function failureCallback(error) {
  console.log('It failed with ' + error)
}

doSomething(successCallback, failureCallback)

但是，如果我们需要把几个异步函数顺序执行的话（异步程序中，程序执行的顺序是不可预测的、也是不确定的，而有时候，函数被调用的上下文是有相互依赖的，所以，我们希望它们能按一定的顺序处理），就会出现了所谓的 Callback Hell 的问题。如下所示：

doSomething(function(result) {
  doSomethingElse(
    result,
    function(newResult) {
      doThirdThing(
        newResult,
        function(finalResult) {
          console.log('Got the final result: ' + finalResult)
        },
        failureCallback
      )
    },
    failureCallback
  )
}, failureCallback)

而这样层层嵌套中需要注册的错误处理函数也有可能是完全不一样的，而且会导致代码非常混乱，难以阅读和维护。

JavaScript 的 Promise 错误处理

在异步编程的实践里，使用 Promise 模式来处理更为优雅。

doSomething()
.then(result => doSomethingElse(result))
.then(newResult => doThirdThing(newResult))
.then(finalResult => {
  console.log(`Got the final result: ${finalResult}`);
}).catch(failureCallback);

上面代码中的 then() 和 catch() 方法就是 Promise 对象的方法，then()方法可以把各个异步的函数给串联起来，而catch() 方法则是出错的处理。

看到上面的那个级联式的调用方式，这就要我们的 doSomething() 函数返回 Promise 对象，下面是这个函数的相关代码示例：

function doSomething() {
	let promise = new Promise();
	let xhr = new XMLHttpRequest();
	xhr.open('GET', 'http://coolshell.cn/....', true);

	xhr.onload = function (e) {
        if (this.status === 200) {
            results = JSON.parse(this.responseText);
            promise.resolve(results); // 成功时，调用 resolve() 方法
        }
    };

    xhr.onerror = function (e) {
        promise.reject(e); // 失败时，调用 reject() 方法
    };

    xhr.send();
    return promise;
}

从上面的代码示例中，我们可以看到，如果成功了，要调用
Promise.resolve() 方法，这样 Promise 对象会继续调用下一个 then()。如果出错了就调用 Promise.reject() 方法，这样就会忽略后面的 then() 直到 catch() 方法。

我们可以看到 Promise.reject() 就像是抛异常一样。这个编程模式让我们的代码组织方便了很多。

另外，多说一句，Promise 还可以同时等待两个不同的异步方法。比如下面的代码所展示的方式：

promise1 = doSomething();
promise2 = doSomethingElse();
Promise.when(promise1, promise2).then( function (result1, result2) {
	... // 处理 result1 和 result2 的代码
}, handleError);

在 ECMAScript 2017 的标准中，我们可以使用async/await 这两个关键字来取代 Promise 对象，这样可以让我们的代码更易读。

比如下面的代码示例：

async function foo() {
  try {
    let result = await doSomething();
    let newResult = await doSomethingElse(result);
    let finalResult = await doThirdThing(newResult);
    console.log(`Got the final result: ${finalResult}`);
  } catch(error) {
    failureCallback(error);
  }
}

如果在函数定义之前使用了 async 关键字，就可以在函数内使用 await。当在 await 某个 Promise 时，函数暂停执行，直至该 Promise 产生结果，并且暂停不会阻塞主线程。如果 Promise resolve，则会返回值。如果 Promise reject，则会抛出拒绝的值。

Java 的 Promise 模式

在 JDK 1.8 里也引入了类似 JavaScript 的玩法 —— CompletableFuture。这个类提供了大量的异步编程中 Promise 的各种方式。

链式处理：

1
2
3

CompletableFuture.supplyAsync(this::findReceiver)
                 .thenApply(this::sendMsg)
                 .thenAccept(this::notify);

上面的这个链式处理和 JavaScript 中的then()方法很像，其中的
supplyAsync() 表示执行一个异步方法，而 thenApply() 表示执行成功后再串联另外一个异步方法，最后是 thenAccept() 来处理最终结果。

下面这个例子是要合并两个异步函数的结果：

String result = CompletableFuture.supplyAsync(() -> {
         return "hello";
     }).thenCombine(CompletableFuture.supplyAsync(() -> {
         return "world";
     }), (s1, s2) -> s1 + " " + s2).join());
System.out.println(result);

接下来，我们再来看一下，Java 这个类相关的异常处理：

CompletableFuture.supplyAsync(Integer::parseInt) // 输入: "ILLEGAL"
			     .thenApply(r -> r * 2 * Math.PI)
			     .thenApply(s -> "apply>> " + s)
			     .exceptionally(ex -> "Error: " + ex.getMessage());

我们要注意到上面代码里的 exceptionally() 方法，这个和 JavaScript Promise 中的 catch() 方法相似。

运行上面的代码，会出现如下输出：

1	Error: java.lang.NumberFormatException: For input string: "ILLEGAL"

也可以这样：

CompletableFuture.supplyAsync(Integer::parseInt) // 输入: "ILLEGAL"
				 .thenApply(r -> r * 2 * Math.PI)
				 .thenApply(s -> "apply>> " + s)
				 .handle((result, ex) -> {
				 	if (result != null) {
				 		return result;
				 	} else {
				 		return "Error handling: " + ex.getMessage();
				 	}
				 });

上面代码中，你可以看到，其使用了 handle() 方法来处理最终的结果，其中包含了异步函数中的错误处理。

错误处理的最佳实践

统一分类的错误字典。无论你是使用错误码还是异常捕捉，都需要认真并统一地做好错误的分类。最好是在一个地方定义相关的错误。比如，HTTP 的 4XX 表示客户端有问题，5XX 则表示服务端有问题。也就是说，你要建立一个错误字典。
同类错误的定义最好是可以扩展的。这一点非常重要，而对于这一点，通过面向对象的继承或是像 Go 语言那样的接口多态可以很好地做到。这样可以方便地重用已有的代码。
定义错误的严重程度。比如，Fatal 表示重大错误，Error 表示资源或需求得不到满足，Warning 表示并不一定是个错误但还是需要引起注意，Info 表示不是错误只是一个信息，Debug 表示这是给内部开发人员用于调试程序的。
错误日志的输出最好使用错误码，而不是错误信息。打印错误日志的时候，应该使用统一的格式。但最好不要用错误信息，而应使用相应的错误码，错误码不一定是数字，也可以是一个能从错误字典里找到的一个唯一的可以让人读懂的关键字。这样，会非常有利于日志分析软件进行自动化监控，而不是要从错误信息中做语义分析。比如：HTTP 的日志中就会有 HTTP 的返回码，如：404。但我更推荐使用像PageNotFound这样的标识，这样人和机器都很容易处理。
忽略错误最好有日志。不然会给维护带来很大的麻烦。
对于同一个地方不停的报错，最好不要都打到日志里。不然这样会导致其它日志被淹没了，也会导致日志文件太大。最好的实践是，打出一个错误以及出现的次数。
不要用错误处理逻辑来处理业务逻辑。也就是说，不要使用异常捕捉这样的方式来处理业务逻辑，而是应该用条件判断。如果一个逻辑控制可以用 if - else 清楚地表达，那就不建议使用异常方式处理。异常捕捉是用来处理不期望发生的事情，而错误码则用来处理可能会发生的事。
对于同类的错误处理，用一样的模式。比如，对于null对象的错误，要么都用返回 null，加上条件检查的模式，要么都用抛 NullPointerException 的方式处理。不要混用，这样有助于代码规范。
尽可能在错误发生的地方处理错误。因为这样会让调用者变得更简单。
向上尽可能地返回原始的错误。如果一定要把错误返回到更高层去处理，那么，应该返回原始的错误，而不是重新发明一个错误。
处理错误时，总是要清理已分配的资源。这点非常关键，使用 RAII 技术，或是 try-catch-finally，或是 Go 的 defer 都可以容易地做到。
不推荐在循环体里处理错误。这里说的是 try-catch，绝大多数的情况你不需要这样做。最好把整个循环体外放在 try 语句块内，而在外面做 catch。
不要把大量的代码都放在一个 try 语句块内。一个 try 语句块内的语句应该是完成一个简单单一的事情。
为你的错误定义提供清楚的文档以及每种错误的代码示例。如果你是做 RESTful API 方面的，使用 Swagger 会帮你很容易搞定这个事。
对于异步的方式，推荐使用 Promise 模式处理错误。对于这一点，JavaScript 中有很好的实践。
对于分布式的系统，推荐使用 APM 相关的软件。尤其是使用 Zipkin 这样的服务调用跟踪的分析来关联错误。

SpringBoot 基本原理

发表于 2020-08-12 更新于 2024-01-27 分类于 Java ，框架， Spring ， Spring综合本文字数： 7.2k 阅读时长 ≈ 7 分钟

SpringBoot 基本原理

SpringBoot 为我们做的自动配置，确实方便快捷，但一直搞不明白它的内部启动原理，这次就来一步步解开 SpringBoot 的神秘面纱，让它不再神秘。

@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

从上面代码可以看出，Annotation 定义（@SpringBootApplication）和类定义（SpringApplication.run）最为耀眼，所以要揭开 SpringBoot 的神秘面纱，我们要从这两位开始就可以了。

SpringBootApplication 背后的秘密

@Target(ElementType.TYPE)            // 注解的适用范围，其中TYPE用于描述类、接口（包括包注解类型）或enum声明
@Retention(RetentionPolicy.RUNTIME)  // 注解的生命周期，保留到class文件中（三个生命周期）
@Documented                          // 表明这个注解应该被javadoc记录
@Inherited                           // 子类可以继承该注解
@SpringBootConfiguration             // 继承了Configuration，表示当前是注解类
@EnableAutoConfiguration             // 开启springboot的注解功能，springboot的四大神器之一，其借助@import的帮助
@ComponentScan(excludeFilters = {    // 扫描路径设置（具体使用待确认）
        @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
        @Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication {
...
}

虽然定义使用了多个 Annotation 进行了原信息标注，但实际上重要的只有三个 Annotation：

@Configuration（@SpringBootConfiguration 点开查看发现里面还是应用了@Configuration）
@EnableAutoConfiguration
@ComponentScan
所以，如果我们使用如下的 SpringBoot 启动类，整个 SpringBoot 应用依然可以与之前的启动类功能对等：

@Configuration
@EnableAutoConfiguration
@ComponentScan
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

每次写这 3 个比较累，所以写一个@SpringBootApplication 方便点。接下来分别介绍这 3 个 Annotation。

@Configuration

这里的@Configuration 对我们来说不陌生，它就是 JavaConfig 形式的 Spring Ioc 容器的配置类使用的那个@Configuration，SpringBoot 社区推荐使用基于 JavaConfig 的配置形式，所以，这里的启动类标注了@Configuration 之后，本身其实也是一个 IoC 容器的配置类。
举几个简单例子回顾下，XML 跟 config 配置方式的区别：

表达形式层面
基于 XML 配置的方式是这样：

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd"
       default-lazy-init="true">
    <!--bean定义-->
</beans>

而基于 JavaConfig 的配置方式是这样：

@Configuration
public class MockConfiguration{
    //bean定义
}

任何一个标注了@Configuration 的 Java 类定义都是一个 JavaConfig 配置类。

1
2
3

<bean id="mockService" class="..MockServiceImpl">
    ...
</bean>

而基于 JavaConfig 的配置形式是这样的：

@Configuration
public class MockConfiguration{
    @Bean
    public MockService mockService(){
        return new MockServiceImpl();
    }
}

任何一个标注了@Bean 的方法，其返回值将作为一个 bean 定义注册到 Spring 的 IoC 容器，方法名将默认成该 bean 定义的 id。

表达依赖注入关系层面
为了表达 bean 与 bean 之间的依赖关系，在 XML 形式中一般是这样：

<bean id="mockService" class="..MockServiceImpl">
    <propery name ="dependencyService" ref="dependencyService" />
</bean>

<bean id="dependencyService" class="DependencyServiceImpl"></bean>

而基于 JavaConfig 的配置形式是这样的：

@Configuration
public class MockConfiguration{
    @Bean
    public MockService mockService(){
        return new MockServiceImpl(dependencyService());
    }

    @Bean
    public DependencyService dependencyService(){
        return new DependencyServiceImpl();
    }
}

如果一个 bean 的定义依赖其他 bean,则直接调用对应的 JavaConfig 类中依赖 bean 的创建方法就可以了。

@ComponentScan

@ComponentScan 这个注解在 Spring 中很重要，它对应 XML 配置中的元素，@ComponentScan 的功能其实就是自动扫描并加载符合条件的组件（比如@Component 和@Repository 等）或者 bean 定义，最终将这些 bean 定义加载到 IoC 容器中。

我们可以通过 basePackages 等属性来细粒度的定制@ComponentScan 自动扫描的范围，如果不指定，则默认 Spring 框架实现会从声明@ComponentScan 所在类的 package 进行扫描。

注：所以 SpringBoot 的启动类最好是放在 root package 下，因为默认不指定 basePackages。

@EnableAutoConfiguration

个人感觉**@EnableAutoConfiguration 这个 Annotation 最为重要**，所以放在最后来解读，大家是否还记得 Spring 框架提供的各种名字为@Enable 开头的 Annotation 定义？比如@EnableScheduling、@EnableCaching、@EnableMBeanExport 等，@EnableAutoConfiguration 的理念和做事方式其实一脉相承，简单概括一下就是，借助@Import 的支持，收集和注册特定场景相关的 bean 定义。

@EnableScheduling是通过@Import 将 Spring 调度框架相关的 bean 定义都加载到 IoC 容器。
@EnableMBeanExport是通过@Import 将 JMX 相关的 bean 定义加载到 IoC 容器。
而**@EnableAutoConfiguration**也是借助@Import 的帮助，将所有符合自动配置条件的 bean 定义加载到 IoC 容器，仅此而已！

@EnableAutoConfiguration 作为一个复合 Annotation,其自身定义关键信息如下：

@SuppressWarnings("deprecation")
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@AutoConfigurationPackage
@Import(EnableAutoConfigurationImportSelector.class)
public @interface EnableAutoConfiguration {
    ...
}

两个比较重要的注解：

@AutoConfigurationPackage：自动配置包

@Import: 导入自动配置的组件

AutoConfigurationPackage 注解：

static class Registrar implements ImportBeanDefinitionRegistrar, DeterminableImports {

        @Override
        public void registerBeanDefinitions(AnnotationMetadata metadata,
                BeanDefinitionRegistry registry) {
            register(registry, new PackageImport(metadata).getPackageName());
        }

它其实是注册了一个 Bean 的定义。

new PackageImport(metadata).getPackageName()，它其实返回了当前主程序类的同级以及子级的包组件。

以上图为例，DemoApplication 是和 demo 包同级，但是 demo2 这个类是 DemoApplication 的父级，和 example 包同级

也就是说，DemoApplication 启动加载的 Bean 中，并不会加载 demo2，这也就是为什么，我们要把 DemoApplication 放在项目的最高级中。

Import(AutoConfigurationImportSelector.class)注解：

可以从图中看出 AutoConfigurationImportSelector 继承了 DeferredImportSelector 继承了 ImportSelector

ImportSelector 有一个方法为：selectImports。

@Override
    public String[] selectImports(AnnotationMetadata annotationMetadata) {
        if (!isEnabled(annotationMetadata)) {
            return NO_IMPORTS;
        }
        AutoConfigurationMetadata autoConfigurationMetadata = AutoConfigurationMetadataLoader
                .loadMetadata(this.beanClassLoader);
        AnnotationAttributes attributes = getAttributes(annotationMetadata);
        List<String> configurations = getCandidateConfigurations(annotationMetadata,
                attributes);
        configurations = removeDuplicates(configurations);
        Set<String> exclusions = getExclusions(annotationMetadata, attributes);
        checkExcludedClasses(configurations, exclusions);
        configurations.removeAll(exclusions);
        configurations = filter(configurations, autoConfigurationMetadata);
        fireAutoConfigurationImportEvents(configurations, exclusions);
        return StringUtils.toStringArray(configurations);
    }

可以看到第九行，它其实是去加载 public static final String FACTORIES_RESOURCE_LOCATION = “META-INF/spring.factories”;外部文件。这个外部文件，有很多自动配置的类。如下：

image

其中，最关键的要属**@Import(EnableAutoConfigurationImportSelector.class)，借助EnableAutoConfigurationImportSelector，@EnableAutoConfiguration可以帮助 SpringBoot 应用将所有符合条件的@Configuration**配置都加载到当前 SpringBoot 创建并使用的 IoC 容器。就像一只“八爪鱼”一样。

自动配置幕后英雄：SpringFactoriesLoader 详解

借助于 Spring 框架原有的一个工具类：SpringFactoriesLoader 的支持，@EnableAutoConfiguration 可以智能的自动配置功效才得以大功告成！

SpringFactoriesLoader 属于 Spring 框架私有的一种扩展方案，其主要功能就是从指定的配置文件 META-INF/spring.factories 加载配置。

public abstract class SpringFactoriesLoader {
    //...
    public static <T> List<T> loadFactories(Class<T> factoryClass, ClassLoader classLoader) {
        ...
    }


    public static List<String> loadFactoryNames(Class<?> factoryClass, ClassLoader classLoader) {
        ....
    }
}

配合**@EnableAutoConfiguration使用的话，它更多是提供一种配置查找的功能支持，即根据@EnableAutoConfiguration 的完整类名 org.springframework.boot.autoconfigure.EnableAutoConfiguration 作为查找的 Key,获取对应的一组@Configuration**类

上图就是从 SpringBoot 的 autoconfigure 依赖包中的 META-INF/spring.factories 配置文件中摘录的一段内容，可以很好地说明问题。

所以，@EnableAutoConfiguration 自动配置的魔法骑士就变成了：从 classpath 中搜寻所有的 META-INF/spring.factories 配置文件，并将其中 org.springframework.boot.autoconfigure.EnableutoConfiguration 对应的配置项通过反射（Java Refletion）实例化为对应的标注了@Configuration 的 JavaConfig 形式的 IoC 容器配置类，然后汇总为一个并加载到 IoC 容器。

参考资料

一文搞懂 springboot 启动原理

SpringBoot 知识图谱

发表于 2020-08-12 更新于 2024-01-27 分类于 Java ，框架， Spring ， Spring综合本文字数： 35k 阅读时长 ≈ 32 分钟

SpringBoot 知识图谱

预警：本文非常长，建议先 mark 后看，也许是最后一次写这么长的文章

说明：前面有 4 个小节关于 Spring 的基础知识，分别是：IOC 容器、JavaConfig、事件监听、SpringFactoriesLoader 详解，它们占据了本文的大部分内容，虽然它们之间可能没有太多的联系，但这些知识对于理解 Spring Boot 的核心原理至关重要，如果你对 Spring 框架烂熟于心，完全可以跳过这 4 个小节。正是因为这个系列的文章是由这些看似不相关的知识点组成，因此取名知识清单。

在过去两三年的 Spring 生态圈，最让人兴奋的莫过于 Spring Boot 框架。或许从命名上就能看出这个框架的设计初衷：快速的启动 Spring 应用。因而 Spring Boot 应用本质上就是一个基于 Spring 框架的应用，它是 Spring 对“约定优先于配置”理念的最佳实践产物，它能够帮助开发者更快速高效地构建基于 Spring 生态圈的应用。

那 Spring Boot 有何魔法？自动配置、起步依赖、Actuator、命令行界面(CLI) 是 Spring Boot 最重要的 4 大核心特性，其中 CLI 是 Spring Boot 的可选特性，虽然它功能强大，但也引入了一套不太常规的开发模型，因而这个系列的文章仅关注其它 3 种特性。如文章标题，本文是这个系列的第一部分，将为你打开 Spring Boot 的大门，重点为你剖析其启动流程以及自动配置实现原理。要掌握这部分核心内容，理解一些 Spring 框架的基础知识，将会让你事半功倍。

一、抛砖引玉：探索 Spring IoC 容器

如果有看过SpringApplication.run()方法的源码，Spring Boot 冗长无比的启动流程一定会让你抓狂，透过现象看本质，SpringApplication 只是将一个典型的 Spring 应用的启动流程进行了扩展，因此，透彻理解 Spring 容器是打开 Spring Boot 大门的一把钥匙。

1.1、Spring IoC 容器

可以把 Spring IoC 容器比作一间餐馆，当你来到餐馆，通常会直接招呼服务员：点菜！至于菜的原料是什么？如何用原料把菜做出来？可能你根本就不关心。IoC 容器也是一样，你只需要告诉它需要某个 bean，它就把对应的实例（instance）扔给你，至于这个 bean 是否依赖其他组件，怎样完成它的初始化，根本就不需要你关心。

作为餐馆，想要做出菜肴，得知道菜的原料和菜谱，同样地，IoC 容器想要管理各个业务对象以及它们之间的依赖关系，需要通过某种途径来记录和管理这些信息。BeanDefinition对象就承担了这个责任：容器中的每一个 bean 都会有一个对应的 BeanDefinition 实例，该实例负责保存 bean 对象的所有必要信息，包括 bean 对象的 class 类型、是否是抽象类、构造方法和参数、其它属性等等。当客户端向容器请求相应对象时，容器就会通过这些信息为客户端返回一个完整可用的 bean 实例。

原材料已经准备好（把 BeanDefinition 看着原料），开始做菜吧，等等，你还需要一份菜谱，BeanDefinitionRegistry和BeanFactory就是这份菜谱，BeanDefinitionRegistry 抽象出 bean 的注册逻辑，而 BeanFactory 则抽象出了 bean 的管理逻辑，而各个 BeanFactory 的实现类就具体承担了 bean 的注册以及管理工作。它们之间的关系就如下图：

BeanFactory、BeanDefinitionRegistry 关系图（来自：Spring 揭秘）

DefaultListableBeanFactory作为一个比较通用的 BeanFactory 实现，它同时也实现了 BeanDefinitionRegistry 接口，因此它就承担了 Bean 的注册管理工作。从图中也可以看出，BeanFactory 接口中主要包含 getBean、containBean、getType、getAliases 等管理 bean 的方法，而 BeanDefinitionRegistry 接口则包含 registerBeanDefinition、removeBeanDefinition、getBeanDefinition 等注册管理 BeanDefinition 的方法。

下面通过一段简单的代码来模拟 BeanFactory 底层是如何工作的：

// 默认容器实现
DefaultListableBeanFactory beanRegistry = new DefaultListableBeanFactory();
// 根据业务对象构造相应的BeanDefinition
AbstractBeanDefinition definition = new RootBeanDefinition(Business.class,true);
// 将bean定义注册到容器中
beanRegistry.registerBeanDefinition("beanName",definition);
// 如果有多个bean，还可以指定各个bean之间的依赖关系
// ........

// 然后可以从容器中获取这个bean的实例
// 注意：这里的beanRegistry其实实现了BeanFactory接口，所以可以强转，
// 单纯的BeanDefinitionRegistry是无法强制转换到BeanFactory类型的
BeanFactory container = (BeanFactory)beanRegistry;
Business business = (Business)container.getBean("beanName");

这段代码仅为了说明 BeanFactory 底层的大致工作流程，实际情况会更加复杂，比如 bean 之间的依赖关系可能定义在外部配置文件(XML/Properties)中、也可能是注解方式。Spring IoC 容器的整个工作流程大致可以分为两个阶段：

①、容器启动阶段

容器启动时，会通过某种途径加载Configuration MetaData。除了代码方式比较直接外，在大部分情况下，容器需要依赖某些工具类，比如：BeanDefinitionReader，BeanDefinitionReader 会对加载的Configuration MetaData进行解析和分析，并将分析后的信息组装为相应的 BeanDefinition，最后把这些保存了 bean 定义的 BeanDefinition，注册到相应的 BeanDefinitionRegistry，这样容器的启动工作就完成了。这个阶段主要完成一些准备性工作，更侧重于 bean 对象管理信息的收集，当然一些验证性或者辅助性的工作也在这一阶段完成。

来看一个简单的例子吧，过往，所有的 bean 都定义在 XML 配置文件中，下面的代码将模拟 BeanFactory 如何从配置文件中加载 bean 的定义以及依赖关系：

// 通常为BeanDefinitionRegistry的实现类，这里以DeFaultListabeBeanFactory为例
BeanDefinitionRegistry beanRegistry = new DefaultListableBeanFactory();
// XmlBeanDefinitionReader实现了BeanDefinitionReader接口，用于解析XML文件
XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReaderImpl(beanRegistry);
// 加载配置文件
beanDefinitionReader.loadBeanDefinitions("classpath:spring-bean.xml");

// 从容器中获取bean实例
BeanFactory container = (BeanFactory)beanRegistry;
Business business = (Business)container.getBean("beanName");

②、Bean 的实例化阶段

经过第一阶段，所有 bean 定义都通过 BeanDefinition 的方式注册到 BeanDefinitionRegistry 中，当某个请求通过容器的 getBean 方法请求某个对象，或者因为依赖关系容器需要隐式的调用 getBean 时，就会触发第二阶段的活动：容器会首先检查所请求的对象之前是否已经实例化完成。如果没有，则会根据注册的 BeanDefinition 所提供的信息实例化被请求对象，并为其注入依赖。当该对象装配完毕后，容器会立即将其返回给请求方法使用。

BeanFactory 只是 Spring IoC 容器的一种实现，如果没有特殊指定，它采用采用延迟初始化策略：只有当访问容器中的某个对象时，才对该对象进行初始化和依赖注入操作。而在实际场景下，我们更多的使用另外一种类型的容器：ApplicationContext，它构建在 BeanFactory 之上，属于更高级的容器，除了具有 BeanFactory 的所有能力之外，还提供对事件监听机制以及国际化的支持等。它管理的 bean，在容器启动时全部完成初始化和依赖注入操作。

1.2、Spring 容器扩展机制

IoC 容器负责管理容器中所有 bean 的生命周期，而在 bean 生命周期的不同阶段，Spring 提供了不同的扩展点来改变 bean 的命运。在容器的启动阶段，BeanFactoryPostProcessor允许我们在容器实例化相应对象之前，对注册到容器的 BeanDefinition 所保存的信息做一些额外的操作，比如修改 bean 定义的某些属性或者增加其他信息等。

如果要自定义扩展类，通常需要实现org.springframework.beans.factory.config.BeanFactoryPostProcessor接口，与此同时，因为容器中可能有多个 BeanFactoryPostProcessor，可能还需要实现org.springframework.core.Ordered接口，以保证 BeanFactoryPostProcessor 按照顺序执行。Spring 提供了为数不多的 BeanFactoryPostProcessor 实现，我们以PropertyPlaceholderConfigurer来说明其大致的工作流程。

在 Spring 项目的 XML 配置文件中，经常可以看到许多配置项的值使用占位符，而将占位符所代表的值单独配置到独立的 properties 文件，这样可以将散落在不同 XML 文件中的配置集中管理，而且也方便运维根据不同的环境进行配置不同的值。这个非常实用的功能就是由 PropertyPlaceholderConfigurer 负责实现的。

根据前文，当 BeanFactory 在第一阶段加载完所有配置信息时，BeanFactory 中保存的对象的属性还是以占位符方式存在的，比如${jdbc.mysql.url}。当 PropertyPlaceholderConfigurer 作为 BeanFactoryPostProcessor 被应用时，它会使用 properties 配置文件中的值来替换相应的 BeanDefinition 中占位符所表示的属性值。当需要实例化 bean 时，bean 定义中的属性值就已经被替换成我们配置的值。当然其实现比上面描述的要复杂一些，这里仅说明其大致工作原理，更详细的实现可以参考其源码。

与之相似的，还有BeanPostProcessor，其存在于对象实例化阶段。跟 BeanFactoryPostProcessor 类似，它会处理容器内所有符合条件并且已经实例化后的对象。简单的对比，BeanFactoryPostProcessor 处理 bean 的定义，而 BeanPostProcessor 则处理 bean 完成实例化后的对象。BeanPostProcessor 定义了两个接口：

public interface BeanPostProcessor {
    // 前置处理
    Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException;
    // 后置处理
    Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException;
}

为了理解这两个方法执行的时机，简单的了解下 bean 的整个生命周期：

postProcessBeforeInitialization()方法与postProcessAfterInitialization()分别对应图中前置处理和后置处理两个步骤将执行的方法。这两个方法中都传入了 bean 对象实例的引用，为扩展容器的对象实例化过程提供了很大便利，在这儿几乎可以对传入的实例执行任何操作。注解、AOP 等功能的实现均大量使用了BeanPostProcessor，比如有一个自定义注解，你完全可以实现 BeanPostProcessor 的接口，在其中判断 bean 对象的脑袋上是否有该注解，如果有，你可以对这个 bean 实例执行任何操作，想想是不是非常的简单？

再来看一个更常见的例子，在 Spring 中经常能够看到各种各样的 Aware 接口，其作用就是在对象实例化完成以后将 Aware 接口定义中规定的依赖注入到当前实例中。比如最常见的ApplicationContextAware接口，实现了这个接口的类都可以获取到一个 ApplicationContext 对象。当容器中每个对象的实例化过程走到 BeanPostProcessor 前置处理这一步时，容器会检测到之前注册到容器的 ApplicationContextAwareProcessor，然后就会调用其 postProcessBeforeInitialization()方法，检查并设置 Aware 相关依赖。看看代码吧，是不是很简单：

// 代码来自：org.springframework.context.support.ApplicationContextAwareProcessor
// 其postProcessBeforeInitialization方法调用了invokeAwareInterfaces方法
private void invokeAwareInterfaces(Object bean) {
    if (bean instanceof EnvironmentAware) {
        ((EnvironmentAware) bean).setEnvironment(this.applicationContext.getEnvironment());
    }
    if (bean instanceof ApplicationContextAware) {
        ((ApplicationContextAware) bean).setApplicationContext(this.applicationContext);
    }
    // ......
}

最后总结一下，本小节内容和你一起回顾了 Spring 容器的部分核心内容，限于篇幅不能写更多，但理解这部分内容，足以让您轻松理解 Spring Boot 的启动原理，如果在后续的学习过程中遇到一些晦涩难懂的知识，再回过头来看看 Spring 的核心知识，也许有意想不到的效果。也许 Spring Boot 的中文资料很少，但 Spring 的中文资料和书籍有太多太多，总有东西能给你启发。

二、夯实基础：JavaConfig 与常见 Annotation

2.1、JavaConfig

我们知道bean是 Spring IOC 中非常核心的概念，Spring 容器负责 bean 的生命周期的管理。在最初，Spring 使用 XML 配置文件的方式来描述 bean 的定义以及相互间的依赖关系，但随着 Spring 的发展，越来越多的人对这种方式表示不满，因为 Spring 项目的所有业务类均以 bean 的形式配置在 XML 文件中，造成了大量的 XML 文件，使项目变得复杂且难以管理。

后来，基于纯 Java Annotation 依赖注入框架Guice出世，其性能明显优于采用 XML 方式的 Spring，甚至有部分人认为，Guice可以完全取代 Spring（Guice仅是一个轻量级 IOC 框架，取代 Spring 还差的挺远）。正是这样的危机感，促使 Spring 及社区推出并持续完善了JavaConfig子项目，它基于 Java 代码和 Annotation 注解来描述 bean 之间的依赖绑定关系。比如，下面是使用 XML 配置方式来描述 bean 的定义：

1	<bean id="bookService" class="cn.moondev.service.BookServiceImpl"></bean>

而基于 JavaConfig 的配置形式是这样的：

@Configuration
public class MoonBookConfiguration {

    // 任何标志了@Bean的方法，其返回值将作为一个bean注册到Spring的IOC容器中
    // 方法名默认成为该bean定义的id
    @Bean
    public BookService bookService() {
        return new BookServiceImpl();
    }
}

如果两个 bean 之间有依赖关系的话，在 XML 配置中应该是这样：

<bean id="bookService" class="cn.moondev.service.BookServiceImpl">
    <property name="dependencyService" ref="dependencyService"/>
</bean>

<bean id="otherService" class="cn.moondev.service.OtherServiceImpl">
    <property name="dependencyService" ref="dependencyService"/>
</bean>

<bean id="dependencyService" class="DependencyServiceImpl"/>

而在 JavaConfig 中则是这样：

@Configuration
public class MoonBookConfiguration {

    // 如果一个bean依赖另一个bean，则直接调用对应JavaConfig类中依赖bean的创建方法即可
    // 这里直接调用dependencyService()
    @Bean
    public BookService bookService() {
        return new BookServiceImpl(dependencyService());
    }

    @Bean
    public OtherService otherService() {
        return new OtherServiceImpl(dependencyService());
    }

    @Bean
    public DependencyService dependencyService() {
        return new DependencyServiceImpl();
    }
}

你可能注意到这个示例中，有两个 bean 都依赖于 dependencyService，也就是说当初始化 bookService 时会调用dependencyService()，在初始化 otherService 时也会调用dependencyService()，那么问题来了？这时候 IOC 容器中是有一个 dependencyService 实例还是两个？这个问题留着大家思考吧，这里不再赘述。

2.2、@ComponentScan

@ComponentScan注解对应 XML 配置形式中的``元素，表示启用组件扫描，Spring 会自动扫描所有通过注解配置的 bean，然后将其注册到 IOC 容器中。我们可以通过basePackages等属性来指定@ComponentScan自动扫描的范围，如果不指定，默认从声明@ComponentScan所在类的package进行扫描。正因为如此，SpringBoot 的启动类都默认在src/main/java下。

2.3、@Import

@Import注解用于导入配置类，举个简单的例子：

@Configuration
public class MoonBookConfiguration {
    @Bean
    public BookService bookService() {
        return new BookServiceImpl();
    }
}

现在有另外一个配置类，比如：MoonUserConfiguration，这个配置类中有一个 bean 依赖于MoonBookConfiguration中的 bookService，如何将这两个 bean 组合在一起？借助@Import即可：

@Configuration
// 可以同时导入多个配置类，比如：@Import({A.class,B.class})
@Import(MoonBookConfiguration.class)
public class MoonUserConfiguration {
    @Bean
    public UserService userService(BookService bookService) {
        return new BookServiceImpl(bookService);
    }
}

需要注意的是，在 4.2 之前，@Import注解只支持导入配置类，但是在 4.2 之后，它支持导入普通类，并将这个类作为一个 bean 的定义注册到 IOC 容器中。

2.4、@Conditional

@Conditional注解表示在满足某种条件后才初始化一个 bean 或者启用某些配置。它一般用在由@Component、@Service、@Configuration等注解标识的类上面，或者由@Bean标记的方法上。如果一个@Configuration类标记了@Conditional，则该类中所有标识了@Bean的方法和@Import注解导入的相关类将遵从这些条件。

在 Spring 里可以很方便的编写你自己的条件类，所要做的就是实现Condition接口，并覆盖它的matches()方法。举个例子，下面的简单条件类表示只有在Classpath里存在JdbcTemplate类时才生效：

public class JdbcTemplateCondition implements Condition {

    @Override
    public boolean matches(ConditionContext conditionContext, AnnotatedTypeMetadata annotatedTypeMetadata) {
        try {
        conditionContext.getClassLoader().loadClass("org.springframework.jdbc.core.JdbcTemplate");
            return true;
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
        return false;
    }
}

当你用 Java 来声明 bean 的时候，可以使用这个自定义条件类：

@Conditional(JdbcTemplateCondition.class)
@Service
public MyService service() {
    ......
}

这个例子中只有当JdbcTemplateCondition类的条件成立时才会创建 MyService 这个 bean。也就是说 MyService 这 bean 的创建条件是classpath里面包含JdbcTemplate，否则这个 bean 的声明就会被忽略掉。

Spring Boot定义了很多有趣的条件，并把他们运用到了配置类上，这些配置类构成了Spring Boot的自动配置的基础。Spring Boot运用条件化配置的方法是：定义多个特殊的条件化注解，并将它们用到配置类上。下面列出了Spring Boot提供的部分条件化注解：

条件化注解	配置生效条件
@ConditionalOnBean	配置了某个特定 bean
@ConditionalOnMissingBean	没有配置特定的 bean
@ConditionalOnClass	Classpath 里有指定的类
@ConditionalOnMissingClass	Classpath 里没有指定的类
@ConditionalOnExpression	给定的 Spring Expression Language 表达式计算结果为 true
@ConditionalOnJava	Java 的版本匹配特定指或者一个范围值
@ConditionalOnProperty	指定的配置属性要有一个明确的值
@ConditionalOnResource	Classpath 里有指定的资源
@ConditionalOnWebApplication	这是一个 Web 应用程序
@ConditionalOnNotWebApplication	这不是一个 Web 应用程序

2.5、@ConfigurationProperties 与@EnableConfigurationProperties

当某些属性的值需要配置的时候，我们一般会在application.properties文件中新建配置项，然后在 bean 中使用@Value注解来获取配置的值，比如下面配置数据源的代码。

// jdbc config
jdbc.mysql.url=jdbc:mysql://localhost:3306/sampledb
jdbc.mysql.username=root
jdbc.mysql.password=123456
......

// 配置数据源
@Configuration
public class HikariDataSourceConfiguration {

    @Value("jdbc.mysql.url")
    public String url;
    @Value("jdbc.mysql.username")
    public String user;
    @Value("jdbc.mysql.password")
    public String password;

    @Bean
    public HikariDataSource dataSource() {
        HikariConfig hikariConfig = new HikariConfig();
        hikariConfig.setJdbcUrl(url);
        hikariConfig.setUsername(user);
        hikariConfig.setPassword(password);
        // 省略部分代码
        return new HikariDataSource(hikariConfig);
    }
}

使用@Value注解注入的属性通常都比较简单，如果同一个配置在多个地方使用，也存在不方便维护的问题（考虑下，如果有几十个地方在使用某个配置，而现在你想改下名字，你改怎么做？）。对于更为复杂的配置，Spring Boot 提供了更优雅的实现方式，那就是@ConfigurationProperties注解。我们可以通过下面的方式来改写上面的代码：

@Component
//  还可以通过@PropertySource("classpath:jdbc.properties")来指定配置文件
@ConfigurationProperties("jdbc.mysql")
// 前缀=jdbc.mysql，会在配置文件中寻找jdbc.mysql.*的配置项
pulic class JdbcConfig {
    public String url;
    public String username;
    public String password;
}

@Configuration
public class HikariDataSourceConfiguration {

    @AutoWired
    public JdbcConfig config;

    @Bean
    public HikariDataSource dataSource() {
        HikariConfig hikariConfig = new HikariConfig();
        hikariConfig.setJdbcUrl(config.url);
        hikariConfig.setUsername(config.username);
        hikariConfig.setPassword(config.password);
        // 省略部分代码
        return new HikariDataSource(hikariConfig);
    }
}

@ConfigurationProperties对于更为复杂的配置，处理起来也是得心应手，比如有如下配置文件：

#App
app.menus[0].title=Home
app.menus[0].name=Home
app.menus[0].path=/
app.menus[1].title=Login
app.menus[1].name=Login
app.menus[1].path=/login

app.compiler.timeout=5
app.compiler.output-folder=/temp/

app.error=/error/

可以定义如下配置类来接收这些属性

@Component
@ConfigurationProperties("app")
public class AppProperties {

    public String error;
    public List<Menu> menus = new ArrayList<>();
    public Compiler compiler = new Compiler();

    public static class Menu {
        public String name;
        public String path;
        public String title;
    }

    public static class Compiler {
        public String timeout;
        public String outputFolder;
    }
}

@EnableConfigurationProperties注解表示对@ConfigurationProperties的内嵌支持，默认会将对应 Properties Class 作为 bean 注入的 IOC 容器中，即在相应的 Properties 类上不用加@Component注解。

三、削铁如泥：SpringFactoriesLoader 详解

JVM 提供了 3 种类加载器：BootstrapClassLoader、ExtClassLoader、AppClassLoader分别加载 Java 核心类库、扩展类库以及应用的类路径(CLASSPATH)下的类库。JVM 通过双亲委派模型进行类的加载，我们也可以通过继承java.lang.classloader实现自己的类加载器。

何为双亲委派模型？当一个类加载器收到类加载任务时，会先交给自己的父加载器去完成，因此最终加载任务都会传递到最顶层的 BootstrapClassLoader，只有当父加载器无法完成加载任务时，才会尝试自己来加载。

采用双亲委派模型的一个好处是保证使用不同类加载器最终得到的都是同一个对象，这样就可以保证 Java 核心库的类型安全，比如，加载位于 rt.jar 包中的java.lang.Object类，不管是哪个加载器加载这个类，最终都是委托给顶层的 BootstrapClassLoader 来加载的，这样就可以保证任何的类加载器最终得到的都是同样一个 Object 对象。查看 ClassLoader 的源码，对双亲委派模型会有更直观的认识：

protected Class<?> loadClass(String name, boolean resolve) {
    synchronized (getClassLoadingLock(name)) {
    // 首先，检查该类是否已经被加载，如果从JVM缓存中找到该类，则直接返回
    Class<?> c = findLoadedClass(name);
    if (c == null) {
        try {
            // 遵循双亲委派的模型，首先会通过递归从父加载器开始找，
            // 直到父类加载器是BootstrapClassLoader为止
            if (parent != null) {
                c = parent.loadClass(name, false);
            } else {
                c = findBootstrapClassOrNull(name);
            }
        } catch (ClassNotFoundException e) {}
        if (c == null) {
            // 如果还找不到，尝试通过findClass方法去寻找
            // findClass是留给开发者自己实现的，也就是说
            // 自定义类加载器时，重写此方法即可
           c = findClass(name);
        }
    }
    if (resolve) {
        resolveClass(c);
    }
    return c;
    }
}

但双亲委派模型并不能解决所有的类加载器问题，比如，Java 提供了很多服务提供者接口(Service Provider Interface，SPI)，允许第三方为这些接口提供实现。常见的 SPI 有 JDBC、JNDI、JAXP 等，这些 SPI 的接口由核心类库提供，却由第三方实现，这样就存在一个问题：SPI 的接口是 Java 核心库的一部分，是由 BootstrapClassLoader 加载的；SPI 实现的 Java 类一般是由 AppClassLoader 来加载的。BootstrapClassLoader 是无法找到 SPI 的实现类的，因为它只加载 Java 的核心库。它也不能代理给 AppClassLoader，因为它是最顶层的类加载器。也就是说，双亲委派模型并不能解决这个问题。

线程上下文类加载器(ContextClassLoader)正好解决了这个问题。从名称上看，可能会误解为它是一种新的类加载器，实际上，它仅仅是 Thread 类的一个变量而已，可以通过setContextClassLoader(ClassLoader cl)和getContextClassLoader()来设置和获取该对象。如果不做任何的设置，Java 应用的线程的上下文类加载器默认就是 AppClassLoader。在核心类库使用 SPI 接口时，传递的类加载器使用线程上下文类加载器，就可以成功的加载到 SPI 实现的类。线程上下文类加载器在很多 SPI 的实现中都会用到。但在 JDBC 中，你可能会看到一种更直接的实现方式，比如，JDBC 驱动管理java.sql.Driver中的loadInitialDrivers()方法中，你可以直接看到 JDK 是如何加载驱动的：

for (String aDriver : driversList) {
    try {
        // 直接使用AppClassLoader
        Class.forName(aDriver, true, ClassLoader.getSystemClassLoader());
    } catch (Exception ex) {
        println("DriverManager.Initialize: load failed: " + ex);
    }
}

其实讲解线程上下文类加载器，最主要是让大家在看到Thread.currentThread().getClassLoader()和Thread.currentThread().getContextClassLoader()时不会一脸懵逼，这两者除了在许多底层框架中取得的 ClassLoader 可能会有所不同外，其他大多数业务场景下都是一样的，大家只要知道它是为了解决什么问题而存在的即可。

类加载器除了加载 class 外，还有一个非常重要功能，就是加载资源，它可以从 jar 包中读取任何资源文件，比如，ClassLoader.getResources(String name)方法就是用于读取 jar 包中的资源文件，其代码如下：

public Enumeration<URL> getResources(String name) throws IOException {
    Enumeration<URL>[] tmp = (Enumeration<URL>[]) new Enumeration<?>[2];
    if (parent != null) {
        tmp[0] = parent.getResources(name);
    } else {
        tmp[0] = getBootstrapResources(name);
    }
    tmp[1] = findResources(name);
    return new CompoundEnumeration<>(tmp);
}

是不是觉得有点眼熟，不错，它的逻辑其实跟类加载的逻辑是一样的，首先判断父类加载器是否为空，不为空则委托父类加载器执行资源查找任务，直到 BootstrapClassLoader，最后才轮到自己查找。而不同的类加载器负责扫描不同路径下的 jar 包，就如同加载 class 一样，最后会扫描所有的 jar 包，找到符合条件的资源文件。

类加载器的findResources(name)方法会遍历其负责加载的所有 jar 包，找到 jar 包中名称为 name 的资源文件，这里的资源可以是任何文件，甚至是.class 文件，比如下面的示例，用于查找 Array.class 文件：

// 寻找Array.class文件
public static void main(String[] args) throws Exception{
    // Array.class的完整路径
    String name = "java/sql/Array.class";
    Enumeration<URL> urls = Thread.currentThread().getContextClassLoader().getResources(name);
    while (urls.hasMoreElements()) {
        URL url = urls.nextElement();
        System.out.println(url.toString());
    }
}

运行后可以得到如下结果：

1	$JAVA_HOME/jre/lib/rt.jar!/java/sql/Array.class

根据资源文件的 URL，可以构造相应的文件来读取资源内容。

看到这里，你可能会感到挺奇怪的，你不是要详解SpringFactoriesLoader吗？上来讲了一堆 ClassLoader 是几个意思？看下它的源码你就知道了：

public static final String FACTORIES_RESOURCE_LOCATION = "META-INF/spring.factories";
// spring.factories文件的格式为：key=value1,value2,value3
// 从所有的jar包中找到META-INF/spring.factories文件
// 然后从文件中解析出key=factoryClass类名称的所有value值
public static List<String> loadFactoryNames(Class<?> factoryClass, ClassLoader classLoader) {
    String factoryClassName = factoryClass.getName();
    // 取得资源文件的URL
    Enumeration<URL> urls = (classLoader != null ? classLoader.getResources(FACTORIES_RESOURCE_LOCATION) : ClassLoader.getSystemResources(FACTORIES_RESOURCE_LOCATION));
    List<String> result = new ArrayList<String>();
    // 遍历所有的URL
    while (urls.hasMoreElements()) {
        URL url = urls.nextElement();
        // 根据资源文件URL解析properties文件
        Properties properties = PropertiesLoaderUtils.loadProperties(new UrlResource(url));
        String factoryClassNames = properties.getProperty(factoryClassName);
        // 组装数据，并返回
        result.addAll(Arrays.asList(StringUtils.commaDelimitedListToStringArray(factoryClassNames)));
    }
    return result;
}

有了前面关于 ClassLoader 的知识，再来理解这段代码，是不是感觉豁然开朗：从CLASSPATH下的每个 Jar 包中搜寻所有META-INF/spring.factories配置文件，然后将解析 properties 文件，找到指定名称的配置后返回。需要注意的是，其实这里不仅仅是会去 ClassPath 路径下查找，会扫描所有路径下的 Jar 包，只不过这个文件只会在 Classpath 下的 jar 包中。来简单看下spring.factories文件的内容吧：

// 来自 org.springframework.boot.autoconfigure下的META-INF/spring.factories
// EnableAutoConfiguration后文会讲到，它用于开启Spring Boot自动配置功能
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
org.springframework.boot.autoconfigure.admin.SpringApplicationAdminJmxAutoConfiguration,\
org.springframework.boot.autoconfigure.aop.AopAutoConfiguration,\
org.springframework.boot.autoconfigure.amqp.RabbitAutoConfiguration\

执行loadFactoryNames(EnableAutoConfiguration.class, classLoader)后，得到对应的一组@Configuration类，
我们就可以通过反射实例化这些类然后注入到 IOC 容器中，最后容器里就有了一系列标注了@Configuration的 JavaConfig 形式的配置类。

这就是SpringFactoriesLoader，它本质上属于 Spring 框架私有的一种扩展方案，类似于 SPI，Spring Boot 在 Spring 基础上的很多核心功能都是基于此，希望大家可以理解。

四、另一件武器：Spring 容器的事件监听机制

过去，事件监听机制多用于图形界面编程，比如：点击按钮、在文本框输入内容等操作被称为事件，而当事件触发时，应用程序作出一定的响应则表示应用监听了这个事件，而在服务器端，事件的监听机制更多的用于异步通知以及监控和异常处理。Java 提供了实现事件监听机制的两个基础类：自定义事件类型扩展自java.util.EventObject、事件的监听器扩展自java.util.EventListener。来看一个简单的实例：简单的监控一个方法的耗时。

首先定义事件类型，通常的做法是扩展 EventObject，随着事件的发生，相应的状态通常都封装在此类中：

public class MethodMonitorEvent extends EventObject {
    // 时间戳，用于记录方法开始执行的时间
    public long timestamp;

    public MethodMonitorEvent(Object source) {
        super(source);
    }
}

事件发布之后，相应的监听器即可对该类型的事件进行处理，我们可以在方法开始执行之前发布一个 begin 事件，在方法执行结束之后发布一个 end 事件，相应地，事件监听器需要提供方法对这两种情况下接收到的事件进行处理：

// 1、定义事件监听接口
public interface MethodMonitorEventListener extends EventListener {
    // 处理方法执行之前发布的事件
    public void onMethodBegin(MethodMonitorEvent event);
    // 处理方法结束时发布的事件
    public void onMethodEnd(MethodMonitorEvent event);
}
// 2、事件监听接口的实现：如何处理
public class AbstractMethodMonitorEventListener implements MethodMonitorEventListener {

    @Override
    public void onMethodBegin(MethodMonitorEvent event) {
        // 记录方法开始执行时的时间
        event.timestamp = System.currentTimeMillis();
    }

    @Override
    public void onMethodEnd(MethodMonitorEvent event) {
        // 计算方法耗时
        long duration = System.currentTimeMillis() - event.timestamp;
        System.out.println("耗时：" + duration);
    }
}

事件监听器接口针对不同的事件发布实际提供相应的处理方法定义，最重要的是，其方法只接收 MethodMonitorEvent 参数，说明这个监听器类只负责监听器对应的事件并进行处理。有了事件和监听器，剩下的就是发布事件，然后让相应的监听器监听并处理。通常情况，我们会有一个事件发布者，它本身作为事件源，在合适的时机，将相应的事件发布给对应的事件监听器：

public class MethodMonitorEventPublisher {

    private List<MethodMonitorEventListener> listeners = new ArrayList<MethodMonitorEventListener>();

    public void methodMonitor() {
        MethodMonitorEvent eventObject = new MethodMonitorEvent(this);
        publishEvent("begin",eventObject);
        // 模拟方法执行：休眠5秒钟
        TimeUnit.SECONDS.sleep(5);
        publishEvent("end",eventObject);

    }

    private void publishEvent(String status,MethodMonitorEvent event) {
        // 避免在事件处理期间，监听器被移除，这里为了安全做一个复制操作
        List<MethodMonitorEventListener> copyListeners = ➥ new ArrayList<MethodMonitorEventListener>(listeners);
        for (MethodMonitorEventListener listener : copyListeners) {
            if ("begin".equals(status)) {
                listener.onMethodBegin(event);
            } else {
                listener.onMethodEnd(event);
            }
        }
    }

    public static void main(String[] args) {
        MethodMonitorEventPublisher publisher = new MethodMonitorEventPublisher();
        publisher.addEventListener(new AbstractMethodMonitorEventListener());
        publisher.methodMonitor();
    }
    // 省略实现
    public void addEventListener(MethodMonitorEventListener listener) {}
    public void removeEventListener(MethodMonitorEventListener listener) {}
    public void removeAllListeners() {}

对于事件发布者（事件源）通常需要关注两点：

在合适的时机发布事件。此例中的 methodMonitor()方法是事件发布的源头，其在方法执行之前和结束之后两个时间点发布 MethodMonitorEvent 事件，每个时间点发布的事件都会传给相应的监听器进行处理。在具体实现时需要注意的是，事件发布是顺序执行，为了不影响处理性能，事件监听器的处理逻辑应尽量简单。
事件监听器的管理。publisher 类中提供了事件监听器的注册与移除方法，这样客户端可以根据实际情况决定是否需要注册新的监听器或者移除某个监听器。如果这里没有提供 remove 方法，那么注册的监听器示例将一直被 MethodMonitorEventPublisher 引用，即使已经废弃不用了，也依然在发布者的监听器列表中，这会导致隐性的内存泄漏。

Spring 容器内的事件监听机制

Spring 的 ApplicationContext 容器内部中的所有事件类型均继承自org.springframework.context.ApplicationEvent，容器中的所有监听器都实现org.springframework.context.ApplicationListener接口，并且以 bean 的形式注册在容器中。一旦在容器内发布 ApplicationEvent 及其子类型的事件，注册到容器的 ApplicationListener 就会对这些事件进行处理。

你应该已经猜到是怎么回事了。

ApplicationEvent 继承自 EventObject，Spring 提供了一些默认的实现，比如：ContextClosedEvent表示容器在即将关闭时发布的事件类型，ContextRefreshedEvent表示容器在初始化或者刷新的时候发布的事件类型……

容器内部使用 ApplicationListener 作为事件监听器接口定义，它继承自 EventListener。ApplicationContext 容器在启动时，会自动识别并加载 EventListener 类型的 bean，一旦容器内有事件发布，将通知这些注册到容器的 EventListener。

ApplicationContext 接口继承了 ApplicationEventPublisher 接口，该接口提供了void publishEvent(ApplicationEvent event)方法定义，不难看出，ApplicationContext 容器担当的就是事件发布者的角色。如果有兴趣可以查看AbstractApplicationContext.publishEvent(ApplicationEvent event)方法的源码：ApplicationContext 将事件的发布以及监听器的管理工作委托给ApplicationEventMulticaster接口的实现类。在容器启动时，会检查容器内是否存在名为 applicationEventMulticaster 的 ApplicationEventMulticaster 对象实例。如果有就使用其提供的实现，没有就默认初始化一个 SimpleApplicationEventMulticaster 作为实现。

最后，如果我们业务需要在容器内部发布事件，只需要为其注入 ApplicationEventPublisher 依赖即可：实现 ApplicationEventPublisherAware 接口或者 ApplicationContextAware 接口(Aware 接口相关内容请回顾上文)。

五、出神入化：揭秘自动配置原理

典型的 Spring Boot 应用的启动类一般均位于src/main/java根路径下，比如MoonApplication类：

@SpringBootApplication
public class MoonApplication {

    public static void main(String[] args) {
        SpringApplication.run(MoonApplication.class, args);
    }
}

其中@SpringBootApplication开启组件扫描和自动配置，而SpringApplication.run则负责启动引导应用程序。@SpringBootApplication是一个复合Annotation，它将三个有用的注解组合在一起：

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(excludeFilters = {
        @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
        @Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication {
    // ......
}

@SpringBootConfiguration就是@Configuration，它是 Spring 框架的注解，标明该类是一个JavaConfig配置类。而@ComponentScan启用组件扫描，前文已经详细讲解过，这里着重关注@EnableAutoConfiguration。

@EnableAutoConfiguration注解表示开启 Spring Boot 自动配置功能，Spring Boot 会根据应用的依赖、自定义的 bean、classpath 下有没有某个类等等因素来猜测你需要的 bean，然后注册到 IOC 容器中。那@EnableAutoConfiguration是如何推算出你的需求？首先看下它的定义：

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@AutoConfigurationPackage
@Import(EnableAutoConfigurationImportSelector.class)
public @interface EnableAutoConfiguration {
    // ......
}

你的关注点应该在@Import(EnableAutoConfigurationImportSelector.class)上了，前文说过，@Import注解用于导入类，并将这个类作为一个 bean 的定义注册到容器中，这里它将把EnableAutoConfigurationImportSelector作为 bean 注入到容器中，而这个类会将所有符合条件的@Configuration 配置都加载到容器中，看看它的代码：

public String[] selectImports(AnnotationMetadata annotationMetadata) {
    // 省略了大部分代码，保留一句核心代码
    // 注意：SpringBoot最近版本中，这句代码被封装在一个单独的方法中
    // SpringFactoriesLoader相关知识请参考前文
    List<String> factories = new ArrayList<String>(new LinkedHashSet<String>(
        SpringFactoriesLoader.loadFactoryNames(EnableAutoConfiguration.class, this.beanClassLoader)));
}

这个类会扫描所有的 jar 包，将所有符合条件的@Configuration 配置类注入的容器中，何为符合条件，看看META-INF/spring.factories的文件内容：

// 来自 org.springframework.boot.autoconfigure下的META-INF/spring.factories
// 配置的key = EnableAutoConfiguration，与代码中一致
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration,\
org.springframework.boot.autoconfigure.aop.AopAutoConfiguration,\
org.springframework.boot.autoconfigure.amqp.RabbitAutoConfiguration\
.....

以DataSourceAutoConfiguration为例，看看 Spring Boot 是如何自动配置的：

@Configuration
@ConditionalOnClass({ DataSource.class, EmbeddedDatabaseType.class })
@EnableConfigurationProperties(DataSourceProperties.class)
@Import({ Registrar.class, DataSourcePoolMetadataProvidersConfiguration.class })
public class DataSourceAutoConfiguration {
}

分别说一说：

@ConditionalOnClass({ DataSource.class, EmbeddedDatabaseType.class })：当 Classpath 中存在 DataSource 或者 EmbeddedDatabaseType 类时才启用这个配置，否则这个配置将被忽略。
@EnableConfigurationProperties(DataSourceProperties.class)：将 DataSource 的默认配置类注入到 IOC 容器中，DataSourceproperties 定义为：

// 提供对datasource配置信息的支持，所有的配置前缀为：spring.datasource
@ConfigurationProperties(prefix = "spring.datasource")
public class DataSourceProperties  {
    private ClassLoader classLoader;
    private Environment environment;
    private String name = "testdb";
    ......
}

@Import({ Registrar.class, DataSourcePoolMetadataProvidersConfiguration.class })：导入其他额外的配置，就以DataSourcePoolMetadataProvidersConfiguration为例吧。

@Configuration
public class DataSourcePoolMetadataProvidersConfiguration {

    @Configuration
    @ConditionalOnClass(org.apache.tomcat.jdbc.pool.DataSource.class)
    static class TomcatDataSourcePoolMetadataProviderConfiguration {
        @Bean
        public DataSourcePoolMetadataProvider tomcatPoolDataSourceMetadataProvider() {
            .....
        }
    }
  ......
}

DataSourcePoolMetadataProvidersConfiguration 是数据库连接池提供者的一个配置类，即 Classpath 中存在org.apache.tomcat.jdbc.pool.DataSource.class，则使用 tomcat-jdbc 连接池，如果 Classpath 中存在HikariDataSource.class则使用 Hikari 连接池。

这里仅描述了 DataSourceAutoConfiguration 的冰山一角，但足以说明 Spring Boot 如何利用条件话配置来实现自动配置的。回顾一下，@EnableAutoConfiguration中导入了 EnableAutoConfigurationImportSelector 类，而这个类的selectImports()通过 SpringFactoriesLoader 得到了大量的配置类，而每一个配置类则根据条件化配置来做出决策，以实现自动配置。

整个流程很清晰，但漏了一个大问题：EnableAutoConfigurationImportSelector.selectImports()是何时执行的？其实这个方法会在容器启动过程中执行：AbstractApplicationContext.refresh()，更多的细节在下一小节中说明。

六、启动引导：Spring Boot 应用启动的秘密

6.1 SpringApplication 初始化

SpringBoot 整个启动流程分为两个步骤：初始化一个 SpringApplication 对象、执行该对象的 run 方法。看下 SpringApplication 的初始化流程，SpringApplication 的构造方法中调用 initialize(Object[] sources)方法，其代码如下：

private void initialize(Object[] sources) {
     if (sources != null && sources.length > 0) {
         this.sources.addAll(Arrays.asList(sources));
     }
     // 判断是否是Web项目
     this.webEnvironment = deduceWebEnvironment();
     setInitializers((Collection) getSpringFactoriesInstances(ApplicationContextInitializer.class));
     setListeners((Collection) getSpringFactoriesInstances(ApplicationListener.class));
     // 找到入口类
     this.mainApplicationClass = deduceMainApplicationClass();
}

初始化流程中最重要的就是通过 SpringFactoriesLoader 找到spring.factories文件中配置的ApplicationContextInitializer和ApplicationListener两个接口的实现类名称，以便后期构造相应的实例。ApplicationContextInitializer的主要目的是在ConfigurableApplicationContext做 refresh 之前，对 ConfigurableApplicationContext 实例做进一步的设置或处理。ConfigurableApplicationContext 继承自 ApplicationContext，其主要提供了对 ApplicationContext 进行设置的能力。

实现一个 ApplicationContextInitializer 非常简单，因为它只有一个方法，但大多数情况下我们没有必要自定义一个 ApplicationContextInitializer，即便是 Spring Boot 框架，它默认也只是注册了两个实现，毕竟 Spring 的容器已经非常成熟和稳定，你没有必要来改变它。

而ApplicationListener的目的就没什么好说的了，它是 Spring 框架对 Java 事件监听机制的一种框架实现，具体内容在前文 Spring 事件监听机制这个小节有详细讲解。这里主要说说，如果你想为 Spring Boot 应用添加监听器，该如何实现？

Spring Boot 提供两种方式来添加自定义监听器：

通过SpringApplication.addListeners(ApplicationListener... listeners)或者SpringApplication.setListeners(Collection> listeners)两个方法来添加一个或者多个自定义监听器
既然 SpringApplication 的初始化流程中已经从spring.factories中获取到ApplicationListener的实现类，那么我们直接在自己的 jar 包的META-INF/spring.factories文件中新增配置即可：

1 2	org.springframework.context.ApplicationListener=\ cn.moondev.listeners.xxxxListener\

关于 SpringApplication 的初始化，我们就说这么多。

6.2 Spring Boot 启动流程

Spring Boot 应用的整个启动流程都封装在 SpringApplication.run 方法中，其整个流程真的是太长太长了，但本质上就是在 Spring 容器启动的基础上做了大量的扩展，按照这个思路来看看源码：

public ConfigurableApplicationContext run(String... args) {
        StopWatch stopWatch = new StopWatch();
        stopWatch.start();
        ConfigurableApplicationContext context = null;
        FailureAnalyzers analyzers = null;
        configureHeadlessProperty();
        // ①
        SpringApplicationRunListeners listeners = getRunListeners(args);
        listeners.starting();
        try {
            // ②
            ApplicationArguments applicationArguments = new DefaultApplicationArguments(args);
            ConfigurableEnvironment environment = prepareEnvironment(listeners,applicationArguments);
            // ③
            Banner printedBanner = printBanner(environment);
            // ④
            context = createApplicationContext();
            // ⑤
            analyzers = new FailureAnalyzers(context);
            // ⑥
            prepareContext(context, environment, listeners, applicationArguments,printedBanner);
            // ⑦
            refreshContext(context);
            // ⑧
            afterRefresh(context, applicationArguments);
            // ⑨
            listeners.finished(context, null);
            stopWatch.stop();
            return context;
        }
        catch (Throwable ex) {
            handleRunFailure(context, listeners, analyzers, ex);
            throw new IllegalStateException(ex);
        }
    }

① 通过 SpringFactoriesLoader 查找并加载所有的SpringApplicationRunListeners，通过调用 starting()方法通知所有的 SpringApplicationRunListeners：应用开始启动了。SpringApplicationRunListeners 其本质上就是一个事件发布者，它在 SpringBoot 应用启动的不同时间点发布不同应用事件类型(ApplicationEvent)，如果有哪些事件监听者(ApplicationListener)对这些事件感兴趣，则可以接收并且处理。还记得初始化流程中，SpringApplication 加载了一系列 ApplicationListener 吗？这个启动流程中没有发现有发布事件的代码，其实都已经在 SpringApplicationRunListeners 这儿实现了。

简单的分析一下其实现流程，首先看下 SpringApplicationRunListener 的源码：

public interface SpringApplicationRunListener {

    // 运行run方法时立即调用此方法，可以用户非常早期的初始化工作
    void starting();

    // Environment准备好后，并且ApplicationContext创建之前调用
    void environmentPrepared(ConfigurableEnvironment environment);

    // ApplicationContext创建好后立即调用
    void contextPrepared(ConfigurableApplicationContext context);

    // ApplicationContext加载完成，在refresh之前调用
    void contextLoaded(ConfigurableApplicationContext context);

    // 当run方法结束之前调用
    void finished(ConfigurableApplicationContext context, Throwable exception);

}

SpringApplicationRunListener 只有一个实现类：EventPublishingRunListener。① 处的代码只会获取到一个 EventPublishingRunListener 的实例，我们来看看 starting()方法的内容：

public void starting() {
    // 发布一个ApplicationStartedEvent
    this.initialMulticaster.multicastEvent(new ApplicationStartedEvent(this.application, this.args));
}

顺着这个逻辑，你可以在 ② 处的prepareEnvironment()方法的源码中找到listeners.environmentPrepared(environment);即 SpringApplicationRunListener 接口的第二个方法，那不出你所料，environmentPrepared()又发布了另外一个事件ApplicationEnvironmentPreparedEvent。接下来会发生什么，就不用我多说了吧。

② 创建并配置当前应用将要使用的Environment，Environment 用于描述应用程序当前的运行环境，其抽象了两个方面的内容：配置文件(profile)和属性(properties)，开发经验丰富的同学对这两个东西一定不会陌生：不同的环境(eg：生产环境、预发布环境)可以使用不同的配置文件，而属性则可以从配置文件、环境变量、命令行参数等来源获取。因此，当 Environment 准备好后，在整个应用的任何时候，都可以从 Environment 中获取资源。

总结起来，② 处的两句代码，主要完成以下几件事：

判断 Environment 是否存在，不存在就创建（如果是 web 项目就创建StandardServletEnvironment，否则创建StandardEnvironment）
配置 Environment：配置 profile 以及 properties
调用 SpringApplicationRunListener 的environmentPrepared()方法，通知事件监听者：应用的 Environment 已经准备好

③、SpringBoot 应用在启动时会输出这样的东西：

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::        (v1.5.6.RELEASE)

如果想把这个东西改成自己的涂鸦，你可以研究以下 Banner 的实现，这个任务就留给你们吧。

④、根据是否是 web 项目，来创建不同的 ApplicationContext 容器。

⑤、创建一系列FailureAnalyzer，创建流程依然是通过 SpringFactoriesLoader 获取到所有实现 FailureAnalyzer 接口的 class，然后在创建对应的实例。FailureAnalyzer 用于分析故障并提供相关诊断信息。

⑥、初始化 ApplicationContext，主要完成以下工作：

将准备好的 Environment 设置给 ApplicationContext
遍历调用所有的 ApplicationContextInitializer 的initialize()方法来对已经创建好的 ApplicationContext 进行进一步的处理
调用 SpringApplicationRunListener 的contextPrepared()方法，通知所有的监听者：ApplicationContext 已经准备完毕
将所有的 bean 加载到容器中
调用 SpringApplicationRunListener 的contextLoaded()方法，通知所有的监听者：ApplicationContext 已经装载完毕

⑦、调用 ApplicationContext 的refresh()方法，完成 IoC 容器可用的最后一道工序。从名字上理解为刷新容器，那何为刷新？就是插手容器的启动，联系一下第一小节的内容。那如何刷新呢？且看下面代码：

1 2	// 摘自refresh()方法中一句代码 invokeBeanFactoryPostProcessors(beanFactory);

看看这个方法的实现：

protected void invokeBeanFactoryPostProcessors(ConfigurableListableBeanFactory beanFactory) {
    PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(beanFactory, getBeanFactoryPostProcessors());
    ......
}

获取到所有的BeanFactoryPostProcessor来对容器做一些额外的操作。BeanFactoryPostProcessor 允许我们在容器实例化相应对象之前，对注册到容器的 BeanDefinition 所保存的信息做一些额外的操作。这里的 getBeanFactoryPostProcessors()方法可以获取到 3 个 Processor：

1
2
3

ConfigurationWarningsApplicationContextInitializer$ConfigurationWarningsPostProcessor
SharedMetadataReaderFactoryContextInitializer$CachingMetadataReaderFactoryPostProcessor
ConfigFileApplicationListener$PropertySourceOrderingPostProcessor

不是有那么多 BeanFactoryPostProcessor 的实现类，为什么这儿只有这 3 个？因为在初始化流程获取到的各种 ApplicationContextInitializer 和 ApplicationListener 中，只有上文 3 个做了类似于如下操作：

1
2
3

public void initialize(ConfigurableApplicationContext context) {
    context.addBeanFactoryPostProcessor(new ConfigurationWarningsPostProcessor(getChecks()));
}

然后你就可以进入到PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors()方法了，这个方法除了会遍历上面的 3 个 BeanFactoryPostProcessor 处理外，还会获取类型为BeanDefinitionRegistryPostProcessor的 bean：org.springframework.context.annotation.internalConfigurationAnnotationProcessor，对应的 Class 为ConfigurationClassPostProcessor。ConfigurationClassPostProcessor用于解析处理各种注解，包括：@Configuration、@ComponentScan、@Import、@PropertySource、@ImportResource、@Bean。当处理@import注解的时候，就会调用自动配置这一小节中的EnableAutoConfigurationImportSelector.selectImports()来完成自动配置功能。其他的这里不再多讲，如果你有兴趣，可以查阅参考资料 6。

⑧、查找当前 context 中是否注册有 CommandLineRunner 和 ApplicationRunner，如果有则遍历执行它们。

⑨、执行所有 SpringApplicationRunListener 的 finished()方法。

这就是 Spring Boot 的整个启动流程，其核心就是在 Spring 容器初始化并启动的基础上加入各种扩展点，这些扩展点包括：ApplicationContextInitializer、ApplicationListener 以及各种 BeanFactoryPostProcessor 等等。你对整个流程的细节不必太过关注，甚至没弄明白也没有关系，你只要理解这些扩展点是在何时如何工作的，能让它们为你所用即可。

整个启动流程确实非常复杂，可以查询参考资料中的部分章节和内容，对照着源码，多看看，我想最终你都能弄清楚的。言而总之，Spring 才是核心，理解清楚 Spring 容器的启动流程，那 Spring Boot 启动流程就不在话下了。

参考资料

[1]王福强著；springboot 揭秘：快速构建微服务体系; 机械工业出版社, 2016
[2]王福强著；spring 揭秘; 人民邮件出版社, 2009
[3]craig walls 著；丁雪丰译；spring boot 实战；中国工信出版集团人民邮电出版社，2016
[4]深入探讨 java 类加载器 : www.ibm.com/developerwo…
[5]spring boot 实战：自动配置原理分析 : blog.csdn.net/liaokailin/…
[6]spring boot实战：spring boot bean加载源码分析： blog.csdn.net/liaokailin/…

领域驱动设计简介

发表于 2020-08-10 更新于 2024-01-27 分类于设计， DDD 本文字数： 5.6k 阅读时长 ≈ 5 分钟

领域驱动设计简介

DDD 简介

软件架构模式的演进

第一阶段是单机架构：采用面向过程的设计方法，系统包括客户端 UI 层和数据库两层，采用 C/S 架构模式，整个系统围绕数据库驱动设计和开发，并且总是从设计数据库和字段开始。

第二阶段是集中式架构：采用面向对象的设计方法，系统包括业务接入层、业务逻辑层和数据库层，采用经典的三层架构，也有部分应用采用传统的 SOA 架构。这种架构容易使系统变得臃肿，可扩展性和弹性伸缩性差。

第三阶段是分布式微服务架构：随着微服务架构理念的提出，集中式架构正向分布式微服务架构演进。微服务架构可以很好地实现应用之间的解耦，解决单体应用扩展性和弹性伸缩能力不足的问题。

在单机和集中式架构时代，系统分析、设计和开发往往是独立、分阶段割裂进行的。

什么是 DDD

DDD 是一种处理高度复杂领域的设计思想，它试图分离技术实现的复杂性，并围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演进的问题。DDD 不是架构，而是一种架构设计方法论，它通过边界划分将复杂业务领域简单化，帮我们设计出清晰的领域和应用边界，可以很容易地实现架构演进。DDD 分为两个思维层面：

战略设计主要从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的上下文边界，上下文边界可以作为微服务设计的参考边界。
战术设计则从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地，包括：聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。

DDD 与微服务的关系

DDD 是一种架构设计方法，微服务是一种架构风格。两者都是为了拆解业务复杂度：合理划分领域边界，持续调整现有架构，优化现有代码，以保持架构和代码的生命力，也就是我们常说的演进式架构。

DDD 主要关注：从业务领域视角划分领域边界，构建通用语言进行高效沟通，通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。

微服务主要关注：运行时的进程间通信、容错和故障隔离，实现去中心化数据管理和去中心化服务治理，关注微服务的独立开发、测试、构建和部署。

DDD 核心概念

域

领域：领域具体指一种特定的范围。领域是用来限定业务边界的，那么就会有大小之分，领域越大，业务范围就越大，反之则相反。
子域：领域可以进一步划分为子领域。我们把划分出来的多个子领域称为子域，每个子域对应一个更小的问题域或更小的业务范围。
核心域：决定产品和公司核心竞争力的子域是核心域。
通用域：同时被多个子域使用的通用功能子域是通用域。
支撑域：还有一种功能子域是必需的，但既非核心域也非通用域，它就是支撑域。

领域的核心思想就是将问题域逐级细分，来降低业务理解和系统实现的复杂度。通过领域细分，逐步缩小微服务需要解决的问题域，构建合适的领域模型，而领域模型映射成系统就是微服务了。

核心域、支撑域和通用域的主要目标是：通过领域划分，区分不同子域在公司内的不同功能属性和重要性，从而公司可对不同子域采取不同的资源投入和建设策略，其关注度也会不一样。

通用语言和上下文边界

通用语言：通过团队交流达成共识性的，能够简单、清晰、准确描述业务涵义和规则的语言。

上下文边界：限界就是领域的边界，而上下文则是语义环境。通过领域的上下文边界，我们就可以在统一的领域边界内用统一的语言进行交流。综合一下，上下文边界的定义就是：用来封装通用语言和领域对象，提供上下文环境，保证在领域之内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。这个边界定义了模型的适用范围，使团队所有成员能够明确地知道什么应该在模型中实现，什么不应该在模型中实现。

实体和值对象

实体是多个属性、操作或行为的载体。在事件风暴中，我们可以根据命令、操作或者事件，找出产生这些行为的业务实体对象，进而按照一定的业务规则将依存度高和业务关联紧密的多个实体对象和值对象进行聚类，形成聚合。你可以这么理解，实体和值对象是组成领域模型的基础单元。

本质上，实体是看得到、摸得着的实实在在的业务对象，实体具有业务属性、业务行为和业务逻辑。而值对象只是若干个属性的集合，只有数据初始化操作和有限的不涉及修改数据的行为，基本不包含业务逻辑。值对象的属性集虽然在物理上独立出来了，但在逻辑上它仍然是实体属性的一部分，用于描述实体的特征。

聚合和聚合跟

领域模型内的实体和值对象就好比个体，而能让实体和值对象协同工作的组织就是聚合，它用来确保这些领域对象在实现共同的业务逻辑时，能保证数据的一致性。

聚合就是由业务和逻辑紧密关联的实体和值对象组合而成的，聚合是数据修改和持久化的基本单元，每一个聚合对应一个仓储，实现数据的持久化。聚合有一个聚合根和上下文边界，这个边界根据业务单一职责和高内聚原则，定义了聚合内部应该包含哪些实体和值对象，而聚合之间的边界是松耦合的。

聚合根的主要目的是为了避免由于复杂数据模型缺少统一的业务规则控制，而导致聚合、实体之间数据不一致性的问题。如果把聚合比作组织，那聚合根就是这个组织的负责人。聚合根也称为根实体，它不仅是实体，还是聚合的管理者。

聚合设计步骤

第 1 步：采用事件风暴，根据业务行为，梳理出所有的实体和值对象。
第 2 步：从众多实体中选出适合作为对象管理者的根实体，也就是聚合根。判断一个实体
是否是聚合根，你可以结合以下场景分析：是否有独立的生命周期？是否有全局唯一 ID？
是否可以创建或修改其它对象？是否有专门的模块来管这个实体。
第 3 步：根据业务单一职责和高内聚原则，找出与聚合根关联的所有紧密依赖的实体和值
对象。
第 4 步：在聚合内根据聚合根、实体和值对象的依赖关系，画出对象的引用和依赖模型。
第 5 步：多个聚合根据业务语义和上下文一起划分到同一个限界上下文内。

聚合设计原则

在一致性边界内建模真正的不变条件。
设计小聚合。
通过唯一标识引用其它聚合。
在边界之外使用最终一致性。
通过应用层实现跨聚合的服务调用。

架构模型

DDD 架构

三层架构向 DDD 分层架构演进，主要发生在业务逻辑层和数据访问层。

DDD 分层架构包含用户接口层、应用层、领域层和基础层。通过这些层次划分，我们可以明确微服务各层的职能，划定各领域对象的边界，确定各领域对象的协作方式。

整洁架构

在整洁架构里，同心圆代表应用软件的不同部分，从里到外依次是领域模型、领域服务、应用服务和最外围的容易变化的内容，比如用户界面和基础设施。

整洁架构最主要的原则是依赖原则，它定义了各层的依赖关系，越往里依赖越低，代码级别越高，越是核心能力。外圆代码依赖只能指向内圆，内圆不需要知道外圆的任何情况。

六边形架构

六边形架构的核心理念是：应用是通过端口与外部进行交互的。我想这也是微服务架构下 API 网关盛行的主要原因吧。

也就是说，在下图的六边形架构中，红圈内的核心业务逻辑（应用程序和领域模型）与外部资源（包括 APP、Web 应用以及数据库资源等）完全隔离，仅通过适配器进行交互。它解决了业务逻辑与用户界面的代码交错问题，很好地实现了前后端分离。六边形架构各层的依赖关系与整洁架构一样，都是由外向内依赖。

六边形架构将系统分为内六边形和外六边形两层，这两层的职能划分如下：

红圈内的六边形实现应用的核心业务逻辑；

外六边形完成外部应用、驱动和基础资源等的交互和访问，对前端应用以 API 主动适配的方式提供服务，对基础资源以依赖倒置被动适配的方式实现资源访问。

三种架构对比

这三种架构模型的设计思想正是微服务架构高内聚低耦合原则的完美体现。

架构模型和中台、微服务的联系

中台本质上是领域的子域，它可能是核心域，也可能是通用域或支撑域。通常大家认为阿里的中台对应 DDD 的通用域，将通用的公共能力沉淀为中台，对外提供通用共享服务。

DDD、中台、微服务这三者之间似乎没什么关联，实际上它们的关系是非常紧密的，组合在一起可以作为
一个理论体系用于你的中台和微服务设计。

中台建设要聚焦领域模型

中台需要站在全企业的高度考虑能力的共享和复用。

中台设计时，我们需要建立中台内所有限界上下文的领域模型，DDD 建模过程中会考虑架构演进和功能的重新组合。领域模型建立的过程会对业务和应用进行清晰的逻辑和物理边界（微服务）划分。领域模型的结果会影响到后续的系统模型、架构模型和代码模型，最终影响到微服务的拆分和项目落地。

微服务要有合理的架构分层

微服务设计要有分层的设计思想，让各层各司其职，建立松耦合的层间关系。

不要把与领域无关的逻辑放在领域层实现，保证领域层的纯洁和领域逻辑的稳定，避免污染领域模型。也不要把领域模型的业务逻辑放在应用层，这样会导致应用层过于庞大，最终领域模型会失焦。

应用和资源的解耦与适配

传统以数据为中心的设计模式，应用会对数据库、缓存、文件系统等基础资源产生严重依赖。

正是由于它们之间的这种强依赖的关系，我们一旦更换基础资源就会对应用产生很大的影响，因此需要为应用和资源解耦。

中台战略

平台不是中台

中台源于平台，但它的战略高度要比平台高很多。

平台只是将部分通用的公共能力独立为共享平台。虽然可以通过 API 或者数据对外提供公共共享服务，解决系统重复建设的问题，但这类平台并没有和企业内的其它平台或应用，实现页面、业务流程和数据从前端到后端的全面融合，并且没有将核心业务服务链路作为一个整体方案考虑，各平台仍然是分离且独立的。

简单的理解就是把传统的前后台体系中的后台进行了细分。阿里巴巴提出了大中台小前台的战略。就是强化业务和技术中台，把前端的应用变得更小更灵活。当中台越强大，能力就越强，越能更好的快速响应前台的业务需求。打个比喻，就是土壤越肥沃，越适合生长不同的生物，打造好的生态系统。

什么是中台

中台是一个基础的理念和架构，我们要把所有的基础服务用中台的思路建设，进行联通，共同支持上端的业务。业务中台更多的是支持在线业务，数据中台提供了基础数据处理能力和很多的数据产品给所有业务方去用。业务中台、数据中台、算法中台等等一起提供对上层业务的支撑。

中台的关键词：共享、联通、融合和创新。联通是前台以及中台之间的联通，融合是前台流程和数据的融合，并以共享的方式支持前端一线业务的发展和创新。其中最关键的是快速响应能力和企业级的无缝联通和融合能力，尤其是对于跨业经营的超大型企业来说至关重要。

数字化转型中台

前中后台协同

前台

在前台设计中我们可以借鉴微前端的设计思想，在企业内不仅实现前端解耦和复用，还可以根据核心链路和业务流程，通过对微前端页面的动态组合和流程编排，实现前台业务的融合。

前端页面可以很自然地融合到不同的终端和渠道应用核心业务链路中，实现前端页面、流程和功能复用。

中台

业务中台的建设可采用领域驱动设计方法，通过领域建模，将可复用的公共能力从各个单体剥离，沉淀并组合，采用微服务架构模式，建设成为可共享的通用能力中台。

同样的，我们可以将核心能力用微服务架构模式，建设成为可面向不同渠道和场景的可复用的核心能力中台。业务中台向前台、第三方和其它中台提供 API 服务，实现通用能力和核心能力的复用。

数据中台的主要目标是打通数据孤岛，实现业务融合和创新，包括三大主要职能：

一是完成企业全域数据的采集与存储，实现各不同业务类别中台数据的汇总和集中管理。
二是按照标准的数据规范或数据模型，将数据按照不同主题域或场景进行加工和处理，形成面向不同主题和场景的数据应用，比如客户视图、代理人视图、渠道视图、机构视图等不同数据体系。
三是建立业务需求驱动的数据体系，基于各个维度的数据，深度萃取数据价值，支持业务和商业模式的创新。

相应的，数据中台的建设就可分为三步走：

第一步实现各中台业务数据的汇集，解决数据孤岛和初级数据共享问题。
第二步实现企业级实时或非实时全维度数据的深度融合、加工和共享。
第三步萃取数据价值，支持业务创新，加速从数据转换为业务价值的过程。

后台

前台主要面向客户以及终端销售者，实现营销推广以及交易转化；中台主要面向运营人员，完成运营支撑；后台主要面向后台管理人员，实现流程审核、内部管理以及后勤支撑，比如采购、人力、财务和 OA 等系统。

DDD、中台和微服务的协作

传统企业可以将需要共享的公共能力进行领域建模，建设可共享的通用中台。除此之外，传统企业还会将核心能力进行领域建模，建设面向不同渠道的可复用的核心中台。

如何构建中台

自顶向下策略

自顶向下的策略适用于全新的应用系统建设，或旧系统推倒重建的情况。这种策略是先做顶层设计，从最高领域逐级分解为中台，分别建立领域模型，根据业务属性分为通用中台或核心中台。领域建模过程主要基于业务现状，暂时不考虑系统现状。

自顶向下策略

自底向上策略适用于遗留系统业务模型的演进式重构。这种策略是基于业务和系统现状完成领域建模。首先分别完成系统所在业务域的领域建模；然后对齐业务域，找出具有同类或相似业务功能的领域模型，对比分析领域模型的差异，重组领域对象，重构领域模型。这个过程会沉淀公共和复用的业务能力，会将分散的业务模型整合。

构建步骤

第一步：锁定系统所在业务域，构建领域模型。

第二步：对齐业务域，构建中台业务模型。

第三步：中台归类，根据领域模型设计微服务。

边界

逻辑边界：微服务内聚合之间的边界是逻辑边界。它是一个虚拟的边界，强调业务的内聚，可根据需要变成物理边界，也就是说聚合也可以独立为微服务。

物理边界：微服务之间的边界是物理边界。它强调微服务部署和运行的隔离，关注微服务的服务调用、容错和运行等。

代码边界：不同层或者聚合之间代码目录的边界是代码边界。它强调的是代码之间的隔离，方便架构演进时代码的重组。

通过以上边界，我们可以让业务能力高内聚、代码松耦合，且清晰的边界，可以快速实现微服务代码的拆分和组合，轻松实现微服务架构演进。但有一点一定要格外注意，边界清晰的微服务，不是大单体向小单体的演进。

参考资料

DDD 实战课

系统架构面试

发表于 2020-08-10 更新于 2024-01-27 分类于设计，架构，综合本文字数： 957 阅读时长 ≈ 1 分钟

系统架构面试

如何设计一个秒杀系统？

秒杀系统的挑战

秒杀的核心问题就是极高并发处理，由于系统要在瞬时承受平时数十倍甚至上百倍的流量，这往往超出系统上限，因此处理秒杀的核心思路是限流和缓存。

秒杀系统的解决思路

系统上有拦截流量：尽可能在上游拦截和限制请求，限制流入后端的量，保证后端系统正常。因为无论多少人参与秒杀，实际成交往往是有限的，而且远小于参加秒杀的人数，因此可以通过前端系统进行拦截，限制最终流入系统的请求数量，来保证系统正常进行。
充分利用缓存：这是一个典型的读多写少的应用场景（一趟火车其实只有 2000 张票，200w 个人来买，最多 2000 个人下单成功，其他人都是查询库存，写比例只有 0.1%，读比例占 99.9%），非常适合使用缓存。

秒杀系统的解决方案

秒杀系统具体方案如下：

（1）浏览器、客户端拦截重复请求

用户点击查询或购买按钮后，禁用按钮，避免用户重复提交请求。
JS 代码中限制用户在限定时间内只允许提交一次请求

基于此，大部分流量已被拦截。

（2）应用层拦截请求

浏览器、客户端拦截重复请求只能应付通过浏览器访问的用户。如果有人通过程序发送 http 请求，则无法拦截。针对这种情况的方案是：

以页面缓存的方式，针对短时间内的同一个访问源（如同一个 IP、同一个 Session、同一个用户 ID 多次发送 HTTP 请求）或同样的查询请求（如大量请求都是查询某类商品的库存），都返回相同的展示页面。

如此限流，又有大部分的流量被拦截

（3）服务层请求拦截与数据缓存

加入有黑客，控制了 10w 台肉鸡（并且假设买票不需要实名认证），前面的的限制都不起作用了。这时应该怎么办？

读请求（查库存） - 对于读请求，直接使用缓存即可，一般缓存服务器单机处理每秒 10w 个请求应该没什么问题。
写请求（下单） - 由于服务层清楚的知道库存数量，所以完全可以根据库存数量进行限流。具体来说，就是把所有下单请求都丢该消息队列中，每次只取有限的写请求去数据层处理。当这些写请求处理完，更新一下缓存中的库存数，再去取下一批写请求，如果库存数不够，则消息队列的写请求全部返回”已售罄”的结果。

参考：

如何设计秒杀系统？ - 阿里云云栖社区的回答 - 知乎

如何设计秒杀系统？ - 网易云的回答 - 知乎

参考资料

Java 面向对象

发表于 2020-08-06 更新于 2024-01-27 分类于 Java ， JavaSE ，基础特性本文字数： 6.9k 阅读时长 ≈ 6 分钟

Java 面向对象

在Java 基本数据类型中我们了解 Java 中支持的基本数据类型（值类型）。本文开始讲解 Java 中重要的引用类型——类。

面向对象

每种编程语言，都有自己的操纵内存中元素的方式。

Java 中提供了基本数据类型，但这还不能满足编写程序时，需要抽象更加复杂数据类型的需要。因此，Java 中，允许开发者通过类（类的机制下面会讲到）创建自定义类型。

有了自定义类型，那么数据类型自然会千变万化，所以，必须要有一定的机制，使得它们仍然保持一些必要的、通用的特性。

Java 世界有一句名言：一切皆为对象。这句话，你可能第一天学 Java 时，就听过了。这不仅仅是一句口号，也体现在 Java 的设计上。

首先，所有 Java 类都继承自 Object 类（从这个名字，就可见一斑）。
几乎所有 Java 对象初始化时，都要使用 new 创建对象（基本数据类型、String、枚举特殊处理），对象存储在堆中。

1
2
3

// 下面两
String s = "abc";
String s = new String("abc");

其中，String s 定义了一个名为 s 的引用，它指向一个 String 类型的对象，而实际的对象是 “abc” 字符串。这就像是，使用遥控器（引用）来操纵电视机（对象）。

与 C/C++ 这类语言不同，程序员只需要通过 new 创建一个对象，但不必负责销毁或结束一个对象。负责运行 Java 程序的 Java 虚拟机有一个垃圾回收器，它会监视 new 创建的对象，一旦发现对象不再被引用，则会释放对象的内存空间。

封装

封装（Encapsulation）是指一种将抽象性函式接口的实现细节部份包装、隐藏起来的方法。

封装最主要的作用在于我们能修改自己的实现代码，而不用修改那些调用我们代码的程序片段。

适当的封装可以让程式码更容易理解与维护，也加强了程式码的安全性。

封装的优点：

良好的封装能够减少耦合。
类内部的结构可以自由修改。
可以对成员变量进行更精确的控制。
隐藏信息，实现细节。

实现封装的步骤：

修改属性的可见性来限制对属性的访问（一般限制为 private）。
对每个值属性提供对外的公共方法访问，也就是创建一对赋取值方法，用于对私有属性的访问。

继承

继承是 java 面向对象编程技术的一块基石，因为它允许创建分等级层次的类。

继承就是子类继承父类的特征和行为，使得子类对象（实例）具有父类的实例域和方法，或子类从父类继承方法，使得子类具有父类相同的行为。

现实中的例子：

狗和鸟都是动物。如果将狗、鸟作为类，它们可以继承动物类。

类的继承形式：

1
2
3

class 父类 {}

class 子类 extends 父类 {}

继承类型

继承的特性

子类可以继承父类的属性和方法。需要注意的是，构造方法除外，构造方法只能被调用，而不能被继承。
子类可以拥有自己的属性和方法，即子类可以对父类进行扩展。
子类可以用自己的方式实现父类的方法。
Java 的继承是单继承，但是可以多重继承，单继承就是一个子类只能继承一个父类，多重继承就是，例如 A 类继承 B 类，B 类继承 C 类，所以按照关系就是 C 类是 B 类的父类，B 类是 A 类的父类，这是 Java 继承区别于 C++ 继承的一个特性。
提高了类之间的耦合性（继承的缺点，耦合度高就会造成代码之间的联系越紧密，代码独立性越差）。

继承关键字

继承可以使用 extends 和 implements 这两个关键字来实现继承，而且所有的类都是继承于 java.lang.Object，当一个类没有继承的两个关键字，则默认继承 Object（这个类在 java.lang 包中，所以不需要 **import**）祖先类。

多态

刚开始学习面向对象编程时，容易被各种术语弄得云里雾里。所以，很多人会死记硬背书中对于术语的定义。

但是，随着应用和理解的深入，应该会渐渐有更进一步的认识，将其融汇贯通的理解。

学习类之前，先让我们思考一个问题：Java 中为什么要引入类机制，设计的初衷是什么？

Java 中提供的基本数据类型，只能表示单一的数值，这用于数值计算，还 OK。但是，如果要抽象模拟现实中更复杂的事物，则无法做到。

试想，如果要让你抽象狗的数据模型，怎么做？狗有眼耳口鼻等器官，有腿，狗有大小，毛色，这些都是它的状态，狗会跑、会叫、会吃东西，这些是它的行为。

类的引入，就是为了抽象这种相对复杂的事物。

对象是用于计算机语言对问题域中事物的描述。对象通过方法和属性来分别描述事物所具有的行为和状态。

类是用于描述同一类的对象的一个抽象的概念，类中定义了这一类对象所具有的行为和状态。

类可以看成是创建 Java 对象的模板。

什么是方法？扩展阅读：面向对象编程的弊端是什么？ - invalid s 的回答

类

与大多数面向对象编程语言一样，Java 使用 class （类）关键字来表示自定义类型。自定义类型是为了更容易抽象现实事物。

在一个类中，可以设置一静一动两种元素：属性（静）和方法（动）。

属性（有的人喜欢称为成员、字段） - 属性抽象的是事物的状态。类属性可以是任何类型的对象。
方法（有的人喜欢称为函数） - 方法抽象的是事物的行为。

类的形式如下：

方法

方法定义

修饰符 返回值类型 方法名(参数类型 参数名){
    ...
    方法体
    ...
    return 返回值;
}

方法包含一个方法头和一个方法体。下面是一个方法的所有部分：

修饰符：修饰符，这是可选的，告诉编译器如何调用该方法。定义了该方法的访问类型。
返回值类型：方法可能有返回值。如果没有返回值，这种情况下，返回值类型应设为 void。
方法名：是方法的实际名称。方法名和参数表共同构成方法签名。
参数类型：参数像是一个占位符。当方法被调用时，传递值给参数。这个值被称为实参或变量。参数列表是指方法的参数类型、顺序和参数的个数。参数是可选的，方法可以不包含任何参数。
方法体：方法体包含具体的语句，定义该方法的功能。

示例：

1
2
3

public static int add(int x, int y) {
   return x + y;
}

方法调用

Java 支持两种调用方法的方式，根据方法是否返回值来选择。

当程序调用一个方法时，程序的控制权交给了被调用的方法。当被调用方法的返回语句执行或者到达方法体闭括号时候交还控制权给程序。

当方法返回一个值的时候，方法调用通常被当做一个值。例如：

1	int larger = max(30, 40);

如果方法返回值是 void，方法调用一定是一条语句。例如，方法 println 返回 void。下面的调用是个语句：

1	System.out.println("Hello World");

构造方法

每个类都有构造方法。如果没有显式地为类定义任何构造方法，Java 编译器将会为该类提供一个默认构造方法。

在创建一个对象的时候，至少要调用一个构造方法。构造方法的名称必须与类同名，一个类可以有多个构造方法。

public class Puppy{
    public Puppy(){
    }

    public Puppy(String name){
        // 这个构造器仅有一个参数：name
    }
}

变量

Java 支持的变量类型有：

局部变量 - 类方法中的变量。
实例变量（也叫成员变量） - 类方法外的变量，不过没有 static 修饰。
类变量（也叫静态变量） - 类方法外的变量，用 static 修饰。

特性对比：

局部变量	实例变量（也叫成员变量）	类变量（也叫静态变量）
局部变量声明在方法、构造方法或者语句块中。	实例变量声明在方法、构造方法和语句块之外。	类变量声明在方法、构造方法和语句块之外。并且以 static 修饰。
局部变量在方法、构造方法、或者语句块被执行的时候创建，当它们执行完成后，变量将会被销毁。	实例变量在对象创建的时候创建，在对象被销毁的时候销毁。	类变量在第一次被访问时创建，在程序结束时销毁。
局部变量没有默认值，所以必须经过初始化，才可以使用。	实例变量具有默认值。数值型变量的默认值是 0，布尔型变量的默认值是 false，引用类型变量的默认值是 null。变量的值可以在声明时指定，也可以在构造方法中指定。	类变量具有默认值。数值型变量的默认值是 0，布尔型变量的默认值是 false，引用类型变量的默认值是 null。变量的值可以在声明时指定，也可以在构造方法中指定。此外，静态变量还可以在静态语句块中初始化。
对于局部变量，如果是基本类型，会把值直接存储在栈；如果是引用类型，会把其对象存储在堆，而把这个对象的引用（指针）存储在栈。	实例变量存储在堆。	类变量存储在静态存储区。
访问修饰符不能用于局部变量。	访问修饰符可以用于实例变量。	访问修饰符可以用于类变量。
局部变量只在声明它的方法、构造方法或者语句块中可见。	实例变量对于类中的方法、构造方法或者语句块是可见的。一般情况下应该把实例变量设为私有。通过使用访问修饰符可以使实例变量对子类可见。	与实例变量具有相似的可见性。但为了对类的使用者可见，大多数静态变量声明为 public 类型。
	实例变量可以直接通过变量名访问。但在静态方法以及其他类中，就应该使用完全限定名：ObejectReference.VariableName。	静态变量可以通过：ClassName.VariableName 的方式访问。
		无论一个类创建了多少个对象，类只拥有类变量的一份拷贝。
		类变量除了被声明为常量外很少使用。

变量修饰符

访问级别修饰符 - 如果变量是实例变量或类变量，可以添加访问级别修饰符（public/protected/private）
静态修饰符 - 如果变量是类变量，需要添加 static 修饰
final - 如果变量使用 final 修饰符，就表示这是一个常量，不能被修改。

创建对象

对象是根据类创建的。在 Java 中，使用关键字 new 来创建一个新的对象。创建对象需要以下三步：

声明：声明一个对象，包括对象名称和对象类型。
实例化：使用关键字 new 来创建一个对象。
初始化：使用 new 创建对象时，会调用构造方法初始化对象。

public class Puppy{
   public Puppy(String name){
      //这个构造器仅有一个参数：name
      System.out.println("小狗的名字是 : " + name );
   }
   public static void main(String[] args){
      // 下面的语句将创建一个Puppy对象
      Puppy myPuppy = new Puppy( "tommy" );
   }
}

访问实例变量和方法

/* 实例化对象 */
ObjectReference = new Constructor();
/* 访问类中的变量 */
ObjectReference.variableName;
/* 访问类中的方法 */
ObjectReference.methodName();

访问权限控制

代码组织

当编译一个 .java 文件时，在 .java 文件中的每个类都会输出一个与类同名的 .class 文件。

MultiClassDemo.java 示例：

class MultiClass1 {}

class MultiClass2 {}

class MultiClass3 {}

public class MultiClassDemo {}

执行 javac MultiClassDemo.java 命令，本地会生成 MultiClass1.class、MultiClass2.class、MultiClass3.class、MultiClassDemo.class 四个文件。

Java 可运行程序是由一组 .class 文件打包并压缩成的一个 .jar 文件。Java 解释器负责这些文件的查找、装载和解释。Java 类库实际上是一组类文件（.java 文件）。

其中每个文件允许有一个 public 类，以及任意数量的非 public 类。
public 类名必须和 .java 文件名完全相同，包括大小写。

程序一般不止一个人编写，会调用系统提供的代码、第三方库中的代码、项目中其他人写的代码等，不同的人因为不同的目的可能定义同样的类名/接口名，这就是命名冲突。

Java 中为了解决命名冲突问题，提供了包（package）和导入（import）机制。

package

包（package）的原则：

包类似于文件夹，文件放在文件夹中，类和接口则放在包中。为了便于组织，文件夹一般是一个有层次的树形结构，包也类似。
包名以逗号 . 分隔，表示层次结构。
Java 中命名包名的一个惯例是使用域名作为前缀，因为域名是唯一的，一般按照域名的反序来定义包名，比如，域名是：apache.org，包名就以 org.apache 开头。
包名和文件目录结构必须完全匹配。Java 解释器运行过程如下：
- 找出环境变量 CLASSPATH，作为 .class 文件的根目录。
- 从根目录开始，获取包名称，并将逗号 . 替换为文件分隔符（反斜杠 /），通过这个路径名称去查找 Java 类。

import

同一个包下的类之间互相引用是不需要包名的，可以直接使用。但如果类不在同一个包内，则必须要知道其所在的包，使用有两种方式：

通过类的完全限定名
通过 import 将用到的类引入到当前类

通过类的完全限定名示例：

public class PackageDemo {
    public static void main (String[]args){
        System.out.println(new java.util.Date());
        System.out.println(new java.util.Date());
    }
}

通过 import 导入其它包的类到当前类：

import java.util.Date;

public class PackageDemo2 {
    public static void main(String[] args) {
        System.out.println(new Date());
        System.out.println(new Date());
    }
}

说明：以上两个示例比较起来，显然是 import 方式，代码更加整洁。

扩展阅读：https://www.cnblogs.com/swiftma/p/5628762.html

访问权限修饰关键字

访问权限控制的等级，从最大权限到最小权限依次为：

1	public > protected > 包访问权限（没有任何关键字）> private

public - 表示任何类都可以访问；
包访问权限 - 包访问权限，没有任何关键字。它表示当前包中的所有其他类都可以访问，但是其它包的类无法访问。
protected - 表示子类可以访问，此外，同一个包内的其他类也可以访问，即使这些类不是子类。
private - 表示其它任何类都无法访问。

接口

接口是对行为的抽象，它是抽象方法的集合，利用接口可以达到 API 定义和实现分离的目的。

接口，不能实例化；不能包含任何非常量成员，任何 field 都是隐含着 public static final 的意义；同时，没有非静态方法实现，也就是说要么是抽象方法，要么是静态方法。

Java 标准类库中，定义了非常多的接口，比如 java.util.List。

1
2
3

public interface Comparable<T> {
    public int compareTo(T o);
}

抽象类

抽象类是不能实例化的类，用 abstract 关键字修饰 class，其目的主要是代码重用。除了不能实例化，形式上和一般的 Java 类并没有太大区别，可以有一个或者多个抽象方法，也可以没有抽象方法。抽象类大多用于抽取相关 Java 类的共用方法实现或者是共同成员变量，然后通过继承的方式达到代码复用的目的。

Java 标准库中，比如 collection 框架，很多通用部分就被抽取成为抽象类，例如 java.util.AbstractList。

抽象类不能被实例化(初学者很容易犯的错)，如果被实例化，就会报错，编译无法通过。只有抽象类的非抽象子类可以创建对象。
抽象类中不一定包含抽象方法，但是有抽象方法的类必定是抽象类。
抽象类中的抽象方法只是声明，不包含方法体，就是不给出方法的具体实现也就是方法的具体功能。
构造方法，类方法（用 static 修饰的方法）不能声明为抽象方法。
抽象类的子类必须给出抽象类中的抽象方法的具体实现，除非该子类也是抽象类。

参考资料

JVM GUI 工具

发表于 2020-07-30 更新于 2024-01-27 分类于 Java ， JavaSE ， JVM 本文字数： 3.7k 阅读时长 ≈ 3 分钟

JVM GUI 工具

Java 程序员免不了故障排查工作，所以经常需要使用一些 JVM 工具。

本文系统性的介绍一下常用的 JVM GUI 工具。

jconsole

jconsole 是 JDK 自带的 GUI 工具。jconsole(Java Monitoring and Management Console) 是一种基于 JMX 的可视化监视与管理工具。

jconsole 的管理功能是针对 JMX MBean 进行管理，由于 MBean 可以使用代码、中间件服务器的管理控制台或所有符合 JMX 规范的软件进行访问。

注意：使用 jconsole 的前提是 Java 应用开启 JMX。

开启 JMX

Java 应用开启 JMX 后，可以使用 jconsole 或 jvisualvm 进行监控 Java 程序的基本信息和运行情况。

开启方法是，在 java 指令后，添加以下参数：

-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Djava.rmi.server.hostname=127.0.0.1
-Dcom.sun.management.jmxremote.port=18888

-Djava.rmi.server.hostname - 指定 Java 程序运行的服务器
-Dcom.sun.management.jmxremote.port - 指定 JMX 服务监听端口

连接 jconsole

如果是本地 Java 进程，jconsole 可以直接绑定连接。

如果是远程 Java 进程，需要连接 Java 进程的 JMX 端口。

Connecting to a JMX Agent Using the JMX Service URL

jconsole 界面

进入 jconsole 应用后，可以看到以下 tab 页面。

概述 - 显示有关 Java VM 和监视值的概述信息。
内存 - 显示有关内存使用的信息。内存页相当于可视化的 jstat 命令。
线程 - 显示有关线程使用的信息。
类 - 显示有关类加载的信息。
VM 摘要 - 显示有关 Java VM 的信息。
MBean - 显示有关 MBean 的信息。

jvisualvm

jvisualvm 是 JDK 自带的 GUI 工具。jvisualvm(All-In-One Java Troubleshooting Tool) 是多合一故障处理工具。它支持运行监视、故障处理、性能分析等功能。

个人觉得 jvisualvm 比 jconsole 好用。

jvisualvm 概述页面

jvisualvm 概述页面可以查看当前 Java 进程的基本信息，如：JDK 版本、Java 进程、JVM 参数等。

jvisualvm 监控页面

在 jvisualvm 监控页面，可以看到 Java 进程的 CPU、内存、类加载、线程的实时变化。

jvisualvm 线程页面

jvisualvm 线程页面展示了当前的线程状态。

jvisualvm 还可以生成线程 Dump 文件，帮助进一步分析线程栈信息。

jvisualvm 抽样器页面

jvisualvm 可以对 CPU、内存进行抽样，帮助我们进行性能分析。

MAT

MAT 即 Eclipse Memory Analyzer Tool 的缩写。

MAT 本身也能够获取堆的二进制快照。该功能将借助 jps 列出当前正在运行的 Java 进程，以供选择并获取快照。由于 jps 会将自己列入其中，因此你会在列表中发现一个已经结束运行的 jps 进程。

MAT 可以独立安装（官方下载地址），也可以作为 Eclipse IDE 的插件安装。

MAT 配置

MAT 解压后，安装目录下有个 MemoryAnalyzer.ini 文件。

MemoryAnalyzer.ini 中有个重要的参数 Xmx 表示最大内存，默认为：-vmargs -Xmx1024m

如果试图用 MAT 导入的 dump 文件超过 1024 M，会报错：

1	An internal error occurred during: "Parsing heap dump from XXX"

此时，可以适当调整 Xmx 大小。如果设置的 Xmx 数值过大，本机内存不足以支撑，启动 MAT 会报错：

1	Failed to create the Java Virtual Machine

MAT 分析

点击 Leak Suspects 可以进入内存泄漏页面。

（1）首先，可以查看饼图了解内存的整体消耗情况

（2）缩小范围，寻找问题疑似点

可以点击进入详情页面，在详情页面 Shortest Paths To the Accumulation Point 表示 GC root 到内存消耗聚集点的最短路径，如果某个内存消耗聚集点有路径到达 GC root，则该内存消耗聚集点不会被当做垃圾被回收。

为了找到内存泄露，我获取了两个堆转储文件，两个文件获取时间间隔是一天（因为内存只是小幅度增长，短时间很难发现问题）。对比两个文件的对象，通过对比后的结果可以很方便定位内存泄露。

MAT 同时打开两个堆转储文件，分别打开 Histogram，如下图。在下图中方框 1 按钮用于对比两个 Histogram，对比后在方框 2 处选择 Group By package，然后对比各对象的变化。不难发现 heap3.hprof 比 heap6.hprof 少了 64 个 eventInfo 对象，如果对代码比较熟悉的话想必这样一个结果是能够给程序员一定的启示的。而我也是根据这个启示差找到了最终内存泄露的位置。

JProfile

JProfiler 是一款性能分析工具。

由于它是收费的，所以我本人使用较少。但是，它确实功能强大，且方便使用，还可以和 Intellij Idea 集成。

Arthas

Arthas 是 Alibaba 开源的 Java 诊断工具，深受开发者喜爱。在线排查问题，无需重启；动态跟踪 Java 代码；实时监控 JVM 状态。

Arthas 支持 JDK 6+，支持 Linux/Mac/Windows，采用命令行交互模式，同时提供丰富的 Tab 自动补全功能，进一步方便进行问题的定位和诊断。

Arthas 基础命令

help——查看命令帮助信息
cat——打印文件内容，和 linux 里的 cat 命令类似
echo–打印参数，和 linux 里的 echo 命令类似
grep——匹配查找，和 linux 里的 grep 命令类似
tee——复制标准输入到标准输出和指定的文件，和 linux 里的 tee 命令类似
pwd——返回当前的工作目录，和 linux 命令类似
cls——清空当前屏幕区域
session——查看当前会话的信息
reset——重置增强类，将被 Arthas 增强过的类全部还原，Arthas 服务端关闭时会重置所有增强过的类
version——输出当前目标 Java 进程所加载的 Arthas 版本号
history——打印命令历史
quit——退出当前 Arthas 客户端，其他 Arthas 客户端不受影响
stop——关闭 Arthas 服务端，所有 Arthas 客户端全部退出
keymap——Arthas 快捷键列表及自定义快捷键

Arthas jvm 相关命令

dashboard——当前系统的实时数据面板
thread——查看当前 JVM 的线程堆栈信息
jvm——查看当前 JVM 的信息
sysprop——查看和修改 JVM 的系统属性
sysenv——查看 JVM 的环境变量
vmoption——查看和修改 JVM 里诊断相关的 option
perfcounter——查看当前 JVM 的 Perf Counter 信息
logger——查看和修改 logger
getstatic——查看类的静态属性
ognl——执行 ognl 表达式
mbean——查看 Mbean 的信息
heapdump——dump java heap, 类似 jmap 命令的 heap dump 功能

Arthas class/classloader 相关命令

sc——查看 JVM 已加载的类信息
sm——查看已加载类的方法信息
jad——反编译指定已加载类的源码
mc——内存编译器，内存编译.java文件为.class文件
redefine——加载外部的.class文件，redefine 到 JVM 里
dump——dump 已加载类的 byte code 到特定目录
classloader——查看 classloader 的继承树，urls，类加载信息，使用 classloader 去 getResource

Arthas monitor/watch/trace 相关命令

请注意，这些命令，都通过字节码增强技术来实现的，会在指定类的方法中插入一些切面来实现数据统计和观测，因此在线上、预发使用时，请尽量明确需要观测的类、方法以及条件，诊断结束要执行 stop 或将增强过的类执行 reset 命令。

monitor——方法执行监控
watch——方法执行数据观测
trace——方法内部调用路径，并输出方法路径上的每个节点上耗时
stack——输出当前方法被调用的调用路径
tt——方法执行数据的时空隧道，记录下指定方法每次调用的入参和返回信息，并能对这些不同的时间下调用进行观测

参考资料

JVM 命令行工具

发表于 2020-07-30 更新于 2024-01-27 分类于 Java ， JavaSE ， JVM 本文字数： 22k 阅读时长 ≈ 20 分钟

JVM 命令行工具

Java 程序员免不了故障排查工作，所以经常需要使用一些 JVM 工具。

JDK 自带了一些实用的命令行工具来监控、分析 JVM 信息，掌握它们，非常有助于 TroubleShooting。

以下是较常用的 JDK 命令行工具：

名称	描述
`jps`	JVM 进程状态工具。显示系统内的所有 JVM 进程。
`jstat`	JVM 统计监控工具。监控虚拟机运行时状态信息，它可以显示出 JVM 进程中的类装载、内存、GC、JIT 编译等运行数据。
`jmap`	JVM 堆内存分析工具。用于打印 JVM 进程对象直方图、类加载统计。并且可以生成堆转储快照（一般称为 heapdump 或 dump 文件）。
`jstack`	JVM 栈查看工具。用于打印 JVM 进程的线程和锁的情况。并且可以生成线程快照（一般称为 threaddump 或 javacore 文件）。
`jhat`	用来分析 jmap 生成的 dump 文件。
`jinfo`	JVM 信息查看工具。用于实时查看和调整 JVM 进程参数。
`jcmd`	JVM 命令行调试工具。用于向 JVM 进程发送调试命令。

jps

jps(JVM Process Status Tool) 是虚拟机进程状态工具。它可以显示指定系统内所有的 HotSpot 虚拟机进程状态信息。jps 通过 RMI 协议查询开启了 RMI 服务的远程虚拟机进程状态。

jps 命令用法

1 2	jps [option] [hostid] jps [-help]

如果不指定 hostid 就默认为当前主机或服务器。

常用参数：

option - 选项参数
- -m - 输出 JVM 启动时传递给 main() 的参数。
- -l - 输出主类的全名，如果进程执行的是 jar 包，输出 jar 路径。
- -v - 显示传递给 JVM 的参数。
- -q - 仅输出本地 JVM 进程 ID。
- -V - 仅输出本地 JVM 标识符。
hostid - RMI 注册表中注册的主机名。如果不指定 hostid 就默认为当前主机或服务器。

其中 option、hostid 参数也可以不写。

jps 使用示例

【示例】列出本地 Java 进程

$ jps
18027 Java2Demo.JAR
18032 jps
18005 jstat

【示例】列出本地 Java 进程 ID

$ jps -q
8841
1292
5398

【示例】列出本地 Java 进程 ID，并输出主类的全名，如果进程执行的是 jar 包，输出 jar 路径

1
2
3

$ jps -l remote.domain
3002 /opt/jdk1.7.0/demo/jfc/Java2D/Java2Demo.JAR
2857 sun.tools.jstatd.jstatd

jstat

jstat(JVM statistics Monitoring)，是虚拟机统计信息监视工具。jstat 用于监视虚拟机运行时状态信息，它可以显示出虚拟机进程中的类装载、内存、垃圾收集、JIT 编译等运行数据。

jstat 命令用法

命令格式：

1	jstat [option] VMID [interval] [count]

常用参数：

option - 选项参数，用于指定用户需要查询的虚拟机信息
- -class - 监视类装载、卸载数量、总空间以及类装载所耗费的时间
- -compiler：显示 JIT 编译的相关信息；
- -gc：监视 Java 堆状况，包括 Eden 区、两个 survivor 区、老年代、永久代等区的容量、已用空间、GC 时间合计等信息。
- -gccapacity：显示各个代的容量以及使用情况；
- -gcmetacapacity：显示 Metaspace 的大小；
- -gcnew：显示新生代信息；
- -gcnewcapacity：显示新生代大小和使用情况；
- -gcold：显示老年代和永久代的信息；
- -gcoldcapacity：显示老年代的大小；
- -gcutil：显示垃圾回收统计信息；
- -gccause：显示垃圾回收的相关信息（通 -gcutil），同时显示最后一次或当前正在发生的垃圾回收的诱因；
- -printcompilation：输出 JIT 编译的方法信息。
VMID - 如果是本地虚拟机进程，则 VMID 与 LVMID 是一致的；如果是远程虚拟机进程，那 VMID 的格式应当是：[protocol:][//]lvmid[@hostname[:port]/servername]
interval - 查询间隔
count - 查询次数

【参考】更详细说明可以参考：jstat 命令查看 jvm 的 GC 情况

jstat 使用示例

类加载统计

使用 jstat -class pid 命令可以查看编译统计信息。

【参数】

Loaded - 加载 class 的数量
Bytes - 所占用空间大小
Unloaded - 未加载数量
Bytes - 未加载占用空间
Time - 时间

【示例】查看类加载信息

1
2
3

$ jstat -class 7129
Loaded  Bytes  Unloaded  Bytes     Time
 26749 50405.3      873  1216.8      19.75

编译统计

使用 jstat -compiler pid 命令可以查看编译统计信息。

【示例】

1
2
3

$ jstat -compiler 7129
Compiled Failed Invalid   Time   FailedType FailedMethod
   42030      2       0   302.53          1 org/apache/felix/framework/BundleWiringImpl$BundleClassLoader findClass

【参数】

Compiled - 编译数量
Failed - 失败数量
Invalid - 不可用数量
Time - 时间
FailedType - 失败类型
FailedMethod - 失败的方法

GC 统计

使用 jstat -gc pid time 命令可以查看 GC 统计信息。

【示例】以 250 毫秒的间隔进行 7 个采样，并显示-gcutil 选项指定的输出。

$ jstat -gcutil 21891 250 7
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  0.00  97.02  70.31  66.80  95.52  89.14      7    0.300     0    0.000    0.300
  0.00  97.02  86.23  66.80  95.52  89.14      7    0.300     0    0.000    0.300
  0.00  97.02  96.53  66.80  95.52  89.14      7    0.300     0    0.000    0.300
 91.03   0.00   1.98  68.19  95.89  91.24      8    0.378     0    0.000    0.378
 91.03   0.00  15.82  68.19  95.89  91.24      8    0.378     0    0.000    0.378
 91.03   0.00  17.80  68.19  95.89  91.24      8    0.378     0    0.000    0.378
 91.03   0.00  17.80  68.19  95.89  91.24      8    0.378     0    0.000    0.378

【示例】以 1 秒的间隔进行 4 个采样，并显示-gc 选项指定的输出。

$ jstat -gc 25196 1s 4
 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT
20928.0 20928.0  0.0    0.0   167936.0  8880.5   838912.0   80291.2   106668.0 100032.1 12772.0 11602.2    760   14.332  580   656.218  670.550
20928.0 20928.0  0.0    0.0   167936.0  8880.5   838912.0   80291.2   106668.0 100032.1 12772.0 11602.2    760   14.332  580   656.218  670.550
20928.0 20928.0  0.0    0.0   167936.0  8880.5   838912.0   80291.2   106668.0 100032.1 12772.0 11602.2    760   14.332  580   656.218  670.550
20928.0 20928.0  0.0    0.0   167936.0  8880.5   838912.0   80291.2   106668.0 100032.1 12772.0 11602.2    760   14.332  580   656.218  670.550

参数说明：

S0C：年轻代中 To Survivor 的容量（单位 KB）；
S1C：年轻代中 From Survivor 的容量（单位 KB）；
S0U：年轻代中 To Survivor 目前已使用空间（单位 KB）；
S1U：年轻代中 From Survivor 目前已使用空间（单位 KB）；
EC：年轻代中 Eden 的容量（单位 KB）；
EU：年轻代中 Eden 目前已使用空间（单位 KB）；
OC：Old 代的容量（单位 KB）；
OU：Old 代目前已使用空间（单位 KB）；
MC：Metaspace 的容量（单位 KB）；
MU：Metaspace 目前已使用空间（单位 KB）；
YGC：从应用程序启动到采样时年轻代中 gc 次数；
YGCT：从应用程序启动到采样时年轻代中 gc 所用时间 (s)；
FGC：从应用程序启动到采样时 old 代（全 gc）gc 次数；
FGCT：从应用程序启动到采样时 old 代（全 gc）gc 所用时间 (s)；
GCT：从应用程序启动到采样时 gc 用的总时间 (s)。

注：更详细的参数含义可以参考官方文档：http://docs.oracle.com/javase/8/docs/technotes/tools/unix/jstat.html

jmap

jmap(JVM Memory Map) 是 Java 内存映像工具。jmap 用于生成堆转储快照（一般称为 heapdump 或 dump 文件）。jmap 不仅能生成 dump 文件，还可以查询 finalize 执行队列、Java 堆和永久代的详细信息，如当前使用率、当前使用的是哪种收集器等。

如果不使用这个命令，还可以使用 -XX:+HeapDumpOnOutOfMemoryError 参数来让虚拟机出现 OOM 的时候，自动生成 dump 文件。

jmap 命令用法

命令格式：

1	jmap [option] pid

option 选项参数：

-dump - 生成堆转储快照。-dump:live 只保存堆中的存活对象。
-finalizerinfo - 显示在 F-Queue 队列等待执行 finalizer 方法的对象
-heap - 显示 Java 堆详细信息。
-histo - 显示堆中对象的统计信息，包括类、实例数量、合计容量。-histo:live 只统计堆中的存活对象。
-permstat - to print permanent generation statistics
-F - 当-dump 没有响应时，强制生成 dump 快照

jstat 使用示例

生成 heapdump 快照

dump 堆到文件，format 指定输出格式，live 指明是活着的对象，file 指定文件名

1
2
3

$ jmap -dump:live,format=b,file=dump.hprof 28920
Dumping heap to /home/xxx/dump.hprof ...
Heap dump file created

dump.hprof 这个后缀是为了后续可以直接用 MAT(Memory Anlysis Tool)等工具打开。

查看实例数最多的类

$ jmap -histo 29527 | head -n 6

 num     #instances         #bytes  class name
----------------------------------------------
   1:      13673280     1438961864  [C
   2:       1207166      411277184  [I
   3:       7382322      347307096  [Ljava.lang.Object;

查看指定进程的堆信息

注意：使用 CMS GC 情况下，jmap -heap PID 的执行有可能会导致 java 进程挂起。

$ jmap -heap 12379
Attaching to process ID 12379, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 17.0-b16

using thread-local object allocation.
Parallel GC with 6 thread(s)

Heap Configuration:
   MinHeapFreeRatio = 40
   MaxHeapFreeRatio = 70
   MaxHeapSize      = 83886080 (80.0MB)
   NewSize          = 1310720 (1.25MB)
   MaxNewSize       = 17592186044415 MB
   OldSize          = 5439488 (5.1875MB)
   NewRatio         = 2
   SurvivorRatio    = 8
   PermSize         = 20971520 (20.0MB)
   MaxPermSize      = 88080384 (84.0MB)

Heap Usage:
PS Young Generation
Eden Space:
   capacity = 9306112 (8.875MB)
   used     = 5375360 (5.1263427734375MB)
   free     = 3930752 (3.7486572265625MB)
   57.761608714788736% used
From Space:
   capacity = 9306112 (8.875MB)
   used     = 3425240 (3.2665634155273438MB)
   free     = 5880872 (5.608436584472656MB)
   36.80634834397007% used
To Space:
   capacity = 9306112 (8.875MB)
   used     = 0 (0.0MB)
   free     = 9306112 (8.875MB)
   0.0% used
PS Old Generation
   capacity = 55967744 (53.375MB)
   used     = 48354640 (46.11457824707031MB)
   free     = 7613104 (7.2604217529296875MB)
   86.39733629427693% used
PS Perm Generation
   capacity = 62062592 (59.1875MB)
   used     = 60243112 (57.452308654785156MB)
   free     = 1819480 (1.7351913452148438MB)
   97.06831451706046% used

jstack

jstack(Stack Trace for java) 是 Java 堆栈跟踪工具。jstack 用来打印目标 Java 进程中各个线程的栈轨迹，以及这些线程所持有的锁，并可以生成 java 虚拟机当前时刻的线程快照（一般称为 threaddump 或 javacore 文件）。

线程快照是当前虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等。

jstack 通常会结合 top -Hp pid 或 pidstat -p pid -t 一起查看具体线程的状态，也经常用来排查一些死锁的异常。

线程出现停顿的时候通过 jstack 来查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做什么事情，或者等待什么资源。如果 java 程序崩溃生成 core 文件，jstack 工具可以用来获得 core 文件的 java stack 和 native stack 的信息，从而可以轻松地知道 java 程序是如何崩溃和在程序何处发生问题。另外，jstack 工具还可以附属到正在运行的 java 程序中，看到当时运行的 java 程序的 java stack 和 native stack 的信息, 如果现在运行的 java 程序呈现 hung 的状态，jstack 是非常有用的。

jstack 命令用法

命令格式：

1	jstack [option] pid

option 选项参数

-F - 当正常输出请求不被响应时，强制输出线程堆栈
-l - 除堆栈外，显示关于锁的附加信息
-m - 打印 java 和 jni 框架的所有栈信息

thread dump 文件

一个 Thread Dump 文件大致可以分为五个部分。

第一部分：Full thread dump identifier

这一部分是内容最开始的部分，展示了快照文件的生成时间和 JVM 的版本信息。

1 2	2017-10-19 10:46:44 Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.79-b02 mixed mode):

第二部分：Java EE middleware, third party & custom application Threads

这是整个文件的核心部分，里面展示了 JavaEE 容器（如 tomcat、resin 等）、自己的程序中所使用的线程信息。

"resin-22129" daemon prio=10 tid=0x00007fbe5c34e000 nid=0x4cb1 waiting on condition [0x00007fbe4ff7c000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:315)
    at com.caucho.env.thread2.ResinThread2.park(ResinThread2.java:196)
    at com.caucho.env.thread2.ResinThread2.runTasks(ResinThread2.java:147)
    at com.caucho.env.thread2.ResinThread2.run(ResinThread2.java:118)

参数说明：

"resin-22129" 线程名称：如果使用 java.lang.Thread 类生成一个线程的时候，线程名称为 Thread-(数字) 的形式，这里是 resin 生成的线程；
daemon 线程类型：线程分为守护线程 (daemon) 和非守护线程 (non-daemon) 两种，通常都是守护线程；
prio=10 线程优先级：默认为 5，数字越大优先级越高；
tid=0x00007fbe5c34e000 JVM 线程的 id：JVM 内部线程的唯一标识，通过 java.lang.Thread.getId()获取，通常用自增的方式实现；
nid=0x4cb1 系统线程 id：对应的系统线程 id（Native Thread ID)，可以通过 top 命令进行查看，现场 id 是十六进制的形式；
waiting on condition 系统线程状态：这里是系统的线程状态；
[0x00007fbe4ff7c000] 起始栈地址：线程堆栈调用的其实内存地址；
java.lang.Thread.State: WAITING (parking) JVM 线程状态：这里标明了线程在代码级别的状态。
线程调用栈信息：下面就是当前线程调用的详细栈信息，用于代码的分析。堆栈信息应该从下向上解读，因为程序调用的顺序是从下向上的。

第三部分：HotSpot VM Thread

这一部分展示了 JVM 内部线程的信息，用于执行内部的原生操作。下面常见的集中内置线程：

“Attach Listener”

该线程负责接收外部命令，执行该命令并把结果返回给调用者，此种类型的线程通常在桌面程序中出现。

1 2	"Attach Listener" daemon prio=5 tid=0x00007fc6b6800800 nid=0x3b07 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE

“DestroyJavaVM”

执行 main() 的线程在执行完之后调用 JNI 中的 jni_DestroyJavaVM() 方法会唤起 DestroyJavaVM 线程，处于等待状态，等待其它线程（java 线程和 native 线程）退出时通知它卸载 JVM。

1 2	"DestroyJavaVM" prio=5 tid=0x00007fc6b3001000 nid=0x1903 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE

“Service Thread”

用于启动服务的线程

1 2	"Service Thread" daemon prio=10 tid=0x00007fbea81b3000 nid=0x5f2 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE

“CompilerThread”

用来调用 JITing，实时编译装卸类。通常 JVM 会启动多个线程来处理这部分工作，线程名称后面的数字也会累加，比如 CompilerThread1。

"C2 CompilerThread1" daemon prio=10 tid=0x00007fbea814b000 nid=0x5f1 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" daemon prio=10 tid=0x00007fbea8142000 nid=0x5f0 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

“Signal Dispatcher”

Attach Listener 线程的职责是接收外部 jvm 命令，当命令接收成功后，会交给 signal dispather 线程去进行分发到各个不同的模块处理命令，并且返回处理结果。
signal dispather 线程也是在第一次接收外部 jvm 命令时，进行初始化工作。

1 2	"Signal Dispatcher" daemon prio=10 tid=0x00007fbea81bf800 nid=0x5ef runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE

“Finalizer”

这个线程也是在 main 线程之后创建的，其优先级为 10，主要用于在垃圾收集前，调用对象的 finalize() 方法；关于 Finalizer 线程的几点：

只有当开始一轮垃圾收集时，才会开始调用 finalize()方法；因此并不是所有对象的 finalize()方法都会被执行；
该线程也是 daemon 线程，因此如果虚拟机中没有其他非 daemon 线程，不管该线程有没有执行完 finalize()方法，JVM 也会退出；
JVM 在垃圾收集时会将失去引用的对象包装成 Finalizer 对象（Reference 的实现），并放入 ReferenceQueue，由 Finalizer 线程来处理；最后将该 Finalizer 对象的引用置为 null，由垃圾收集器来回收；

JVM 为什么要单独用一个线程来执行 finalize() 方法呢？

如果 JVM 的垃圾收集线程自己来做，很有可能由于在 finalize()方法中误操作导致 GC 线程停止或不可控，这对 GC 线程来说是一种灾难。

"Finalizer" daemon prio=10 tid=0x00007fbea80da000 nid=0x5eb in Object.wait() [0x00007fbeac044000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
    - locked <0x00000006d173c1a8> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
    at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

“Reference Handler”

JVM 在创建 main 线程后就创建 Reference Handler 线程，其优先级最高，为 10，它主要用于处理引用对象本身（软引用、弱引用、虚引用）的垃圾回收问题。

"Reference Handler" daemon prio=10 tid=0x00007fbea80d8000 nid=0x5ea in Object.wait() [0x00007fbeac085000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    at java.lang.Object.wait(Object.java:503)
    at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
    - locked <0x00000006d173c1f0> (a java.lang.ref.Reference$Lock)

“VM Thread”

JVM 中线程的母体，根据 HotSpot 源码中关于 vmThread.hpp 里面的注释，它是一个单例的对象（最原始的线程）会产生或触发所有其他的线程，这个单例的 VM 线程是会被其他线程所使用来做一些 VM 操作（如清扫垃圾等）。
在 VM Thread 的结构体里有一个 VMOperationQueue 列队，所有的 VM 线程操作(vm_operation)都会被保存到这个列队当中，VMThread 本身就是一个线程，它的线程负责执行一个自轮询的 loop 函数(具体可以参考：VMThread.cpp 里面的 void VMThread::loop()) ，该 loop 函数从 VMOperationQueue 列队中按照优先级取出当前需要执行的操作对象(VM_Operation)，并且调用 VM_Operation->evaluate 函数去执行该操作类型本身的业务逻辑。
VM 操作类型被定义在 vm_operations.hpp 文件内，列举几个：ThreadStop、ThreadDump、PrintThreads、GenCollectFull、GenCollectFullConcurrent、CMS_Initial_Mark、CMS_Final_Remark….. 有兴趣的同学，可以自己去查看源文件。

1	"VM Thread" prio=10 tid=0x00007fbea80d3800 nid=0x5e9 runnable

第四部分：HotSpot GC Thread

JVM 中用于进行资源回收的线程，包括以下几种类型的线程：

“VM Periodic Task Thread”

该线程是 JVM 周期性任务调度的线程，它由 WatcherThread 创建，是一个单例对象。该线程在 JVM 内使用得比较频繁，比如：定期的内存监控、JVM 运行状况监控。

1	"VM Periodic Task Thread" prio=10 tid=0x00007fbea82ae800 nid=0x5fa waiting on condition

可以使用 jstat 命令查看 GC 的情况，比如查看某个进程没有存活必要的引用可以使用命令 jstat -gcutil 250 7 参数中 pid 是进程 id，后面的 250 和 7 表示每 250 毫秒打印一次，总共打印 7 次。
这对于防止因为应用代码中直接使用 native 库或者第三方的一些监控工具的内存泄漏有非常大的帮助。

“GC task thread#0 (ParallelGC)”

垃圾回收线程，该线程会负责进行垃圾回收。通常 JVM 会启动多个线程来处理这个工作，线程名称中#后面的数字也会累加。

"GC task thread#0 (ParallelGC)" prio=5 tid=0x00007fc6b480d000 nid=0x2503 runnable

"GC task thread#1 (ParallelGC)" prio=5 tid=0x00007fc6b2812000 nid=0x2703 runnable

"GC task thread#2 (ParallelGC)" prio=5 tid=0x00007fc6b2812800 nid=0x2903 runnable

"GC task thread#3 (ParallelGC)" prio=5 tid=0x00007fc6b2813000 nid=0x2b03 runnable

如果在 JVM 中增加了 -XX:+UseConcMarkSweepGC 参数将会启用 CMS （Concurrent Mark-Sweep）GC Thread 方式，以下是该模式下的线程类型：

“Gang worker#0 (Parallel GC Threads)”

原来垃圾回收线程 GC task thread#0 (ParallelGC) 被替换为 Gang worker#0 (Parallel GC Threads)。Gang worker 是 JVM 用于年轻代垃圾回收(minor gc)的线程。

1
2
3

"Gang worker#0 (Parallel GC Threads)" prio=10 tid=0x00007fbea801b800 nid=0x5e4 runnable

"Gang worker#1 (Parallel GC Threads)" prio=10 tid=0x00007fbea801d800 nid=0x5e7 runnable

“Concurrent Mark-Sweep GC Thread”

并发标记清除垃圾回收器（就是通常所说的 CMS GC）线程，该线程主要针对于年老代垃圾回收。

1	"Concurrent Mark-Sweep GC Thread" prio=10 tid=0x00007fbea8073800 nid=0x5e8 runnable

“Surrogate Locker Thread (Concurrent GC)”

此线程主要配合 CMS 垃圾回收器来使用，是一个守护线程，主要负责处理 GC 过程中 Java 层的 Reference（指软引用、弱引用等等）与 jvm 内部层面的对象状态同步。

1 2	"Surrogate Locker Thread (Concurrent GC)" daemon prio=10 tid=0x00007fbea8158800 nid=0x5ee waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE

这里以 WeakHashMap 为例进行说明，首先是一个关键点：

WeakHashMap 和 HashMap 一样，内部有一个 Entry[]数组;
WeakHashMap 的 Entry 比较特殊，它的继承体系结构为 Entry->WeakReference->Reference;
Reference 里面有一个全局锁对象：Lock，它也被称为 pending_lock，注意：它是静态对象；
Reference 里面有一个静态变量：pending；
Reference 里面有一个静态内部类：ReferenceHandler 的线程，它在 static 块里面被初始化并且启动，启动完成后处于 wait 状态，它在一个 Lock 同步锁模块中等待；
WeakHashMap 里面还实例化了一个 ReferenceQueue 列队

假设，WeakHashMap 对象里面已经保存了很多对象的引用，JVM 在进行 CMS GC 的时候会创建一个 ConcurrentMarkSweepThread（简称 CMST）线程去进行 GC。ConcurrentMarkSweepThread 线程被创建的同时会创建一个 SurrogateLockerThread（简称 SLT）线程并且启动它，SLT 启动之后，处于等待阶段。
CMST 开始 GC 时，会发一个消息给 SLT 让它去获取 Java 层 Reference 对象的全局锁：Lock。直到 CMS GC 完毕之后，JVM 会将 WeakHashMap 中所有被回收的对象所属的 WeakReference 容器对象放入到 Reference 的 pending 属性当中（每次 GC 完毕之后，pending 属性基本上都不会为 null 了），然后通知 SLT 释放并且 notify 全局锁:Lock。此时激活了 ReferenceHandler 线程的 run 方法，使其脱离 wait 状态，开始工作了。
ReferenceHandler 这个线程会将 pending 中的所有 WeakReference 对象都移动到它们各自的列队当中，比如当前这个 WeakReference 属于某个 WeakHashMap 对象，那么它就会被放入相应的 ReferenceQueue 列队里面（该列队是链表结构）。当我们下次从 WeakHashMap 对象里面 get、put 数据或者调用 size 方法的时候，WeakHashMap 就会将 ReferenceQueue 列队中的 WeakReference 依依 poll 出来去和 Entry[]数据做比较，如果发现相同的，则说明这个 Entry 所保存的对象已经被 GC 掉了，那么将 Entry[]内的 Entry 对象剔除掉。

第五部分：JNI global references count

这一部分主要回收那些在 native 代码上被引用，但在 java 代码中却没有存活必要的引用，对于防止因为应用代码中直接使用 native 库或第三方的一些监控工具的内存泄漏有非常大的帮助。

1	JNI global references: 830

下一篇文章将要讲述一个直接找出 CPU 100% 线程的例子。

系统线程状态

系统线程有如下状态：

deadlock

死锁线程，一般指多个线程调用期间进入了相互资源占用，导致一直等待无法释放的情况。

【示例】deadlock 示例

"DEADLOCK_TEST-1" daemon prio=6 tid=0x000000000690f800 nid=0x1820 waiting for monitor entry [0x000000000805f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
                at com.nbp.theplatform.threaddump.ThreadDeadLockState$DeadlockThread.goMonitorDeadlock(ThreadDeadLockState.java:197)
                - waiting to lock <0x00000007d58f5e60> (a com.nbp.theplatform.threaddump.ThreadDeadLockState$Monitor)
                at com.nbp.theplatform.threaddump.ThreadDeadLockState$DeadlockThread.monitorOurLock(ThreadDeadLockState.java:182)
                - locked <0x00000007d58f5e48> (a com.nbp.theplatform.threaddump.ThreadDeadLockState$Monitor)
                at com.nbp.theplatform.threaddump.ThreadDeadLockState$DeadlockThread.run(ThreadDeadLockState.java:135)

   Locked ownable synchronizers:
                - None

"DEADLOCK_TEST-2" daemon prio=6 tid=0x0000000006858800 nid=0x17b8 waiting for monitor entry [0x000000000815f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
                at com.nbp.theplatform.threaddump.ThreadDeadLockState$DeadlockThread.goMonitorDeadlock(ThreadDeadLockState.java:197)
                - waiting to lock <0x00000007d58f5e78> (a com.nbp.theplatform.threaddump.ThreadDeadLockState$Monitor)
                at com.nbp.theplatform.threaddump.ThreadDeadLockState$DeadlockThread.monitorOurLock(ThreadDeadLockState.java:182)
                - locked <0x00000007d58f5e60> (a com.nbp.theplatform.threaddump.ThreadDeadLockState$Monitor)
                at com.nbp.theplatform.threaddump.ThreadDeadLockState$DeadlockThread.run(ThreadDeadLockState.java:135)

   Locked ownable synchronizers:
                - None

"DEADLOCK_TEST-3" daemon prio=6 tid=0x0000000006859000 nid=0x25dc waiting for monitor entry [0x000000000825f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
                at com.nbp.theplatform.threaddump.ThreadDeadLockState$DeadlockThread.goMonitorDeadlock(ThreadDeadLockState.java:197)
                - waiting to lock <0x00000007d58f5e48> (a com.nbp.theplatform.threaddump.ThreadDeadLockState$Monitor)
                at com.nbp.theplatform.threaddump.ThreadDeadLockState$DeadlockThread.monitorOurLock(ThreadDeadLockState.java:182)
                - locked <0x00000007d58f5e78> (a com.nbp.theplatform.threaddump.ThreadDeadLockState$Monitor)
                at com.nbp.theplatform.threaddump.ThreadDeadLockState$DeadlockThread.run(ThreadDeadLockState.java:135)

   Locked ownable synchronizers:
                - None

runnable

一般指该线程正在执行状态中，该线程占用了资源，正在处理某个操作，如通过 SQL 语句查询数据库、对某个文件进行写入等。

blocked

线程正处于阻塞状态，指当前线程执行过程中，所需要的资源长时间等待却一直未能获取到，被容器的线程管理器标识为阻塞状态，可以理解为等待资源超时的线程。

【示例】blocked 示例

"BLOCKED_TEST pool-1-thread-2" prio=6 tid=0x0000000007673800 nid=0x260c waiting for monitor entry [0x0000000008abf000]
   java.lang.Thread.State: BLOCKED (on object monitor)
                at com.nbp.theplatform.threaddump.ThreadBlockedState.monitorLock(ThreadBlockedState.java:43)
                - waiting to lock <0x0000000780a000b0> (a com.nbp.theplatform.threaddump.ThreadBlockedState)
                at com.nbp.theplatform.threaddump.ThreadBlockedState$2.run(ThreadBlockedState.java:26)
                at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
                at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
                at java.lang.Thread.run(Thread.java:662)
   Locked ownable synchronizers:
                - <0x0000000780b0c6a0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
"BLOCKED_TEST pool-1-thread-3" prio=6 tid=0x00000000074f5800 nid=0x1994 waiting for monitor entry [0x0000000008bbf000]
   java.lang.Thread.State: BLOCKED (on object monitor)
                at com.nbp.theplatform.threaddump.ThreadBlockedState.monitorLock(ThreadBlockedState.java:42)
                - waiting to lock <0x0000000780a000b0> (a com.nbp.theplatform.threaddump.ThreadBlockedState)
                at com.nbp.theplatform.threaddump.ThreadBlockedState$3.run(ThreadBlockedState.java:34)
                at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886
                at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
                at java.lang.Thread.run(Thread.java:662)
   Locked ownable synchronizers:
                - <0x0000000780b0e1b8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)

waiting on condition

线程正处于等待资源或等待某个条件的发生，具体的原因需要结合下面堆栈信息进行分析。

（1）如果堆栈信息明确是应用代码，则证明该线程正在等待资源，一般是大量读取某种资源且该资源采用了资源锁的情况下，线程进入等待状态，等待资源的读取，或者正在等待其他线程的执行等。

（2）如果发现有大量的线程都正处于这种状态，并且堆栈信息中得知正等待网络读写，这是因为网络阻塞导致线程无法执行，很有可能是一个网络瓶颈的征兆：

网络非常繁忙，几乎消耗了所有的带宽，仍然有大量数据等待网络读写；
网络可能是空闲的，但由于路由或防火墙等原因，导致包无法正常到达；

所以一定要结合系统的一些性能观察工具进行综合分析，比如 netstat 统计单位时间的发送包的数量，看是否很明显超过了所在网络带宽的限制；观察 CPU 的利用率，看系统态的 CPU 时间是否明显大于用户态的 CPU 时间。这些都指向由于网络带宽所限导致的网络瓶颈。

（3）还有一种常见的情况是该线程在 sleep，等待 sleep 的时间到了，将被唤醒。

【示例】等待状态样例

"IoWaitThread" prio=6 tid=0x0000000007334800 nid=0x2b3c waiting on condition [0x000000000893f000]
  java.lang.Thread.State: WAITING (parking)
               at sun.misc.Unsafe.park(Native Method)
               - parking to wait for  <0x00000007d5c45850> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
               at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
               at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
               at java.util.concurrent.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:440)
               at java.util.concurrent.LinkedBlockingDeque.take(LinkedBlockingDeque.java:629)
               at com.nbp.theplatform.threaddump.ThreadIoWaitState$IoWaitHandler2.run(ThreadIoWaitState.java:89)
               at java.lang.Thread.run(Thread.java:662)

waiting for monitor entry 或 in Object.wait()

Moniter 是 Java 中用以实现线程之间的互斥与协作的主要手段，它可以看成是对象或者 class 的锁，每个对象都有，也仅有一个 Monitor。

从上图可以看出，每个 Monitor 在某个时刻只能被一个线程拥有，该线程就是 “Active Thread”，而其他线程都是 “Waiting Thread”，分别在两个队列 “Entry Set”和”Waint Set”里面等待。其中在 “Entry Set” 中等待的线程状态是 waiting for monitor entry，在 “Wait Set” 中等待的线程状态是 in Object.wait()。

（1）”Entry Set”里面的线程。

我们称被 synchronized 保护起来的代码段为临界区，对应的代码如下：

1 2	synchronized(obj) { }

当一个线程申请进入临界区时，它就进入了 “Entry Set” 队列中，这时候有两种可能性：

该 Monitor 不被其他线程拥有，”Entry Set”里面也没有其他等待的线程。本线程即成为相应类或者对象的 Monitor 的 Owner，执行临界区里面的代码；此时在 Thread Dump 中显示线程处于 “Runnable” 状态。
该 Monitor 被其他线程拥有，本线程在 “Entry Set” 队列中等待。此时在 Thread Dump 中显示线程处于 “waiting for monity entry” 状态。

临界区的设置是为了保证其内部的代码执行的原子性和完整性，但因为临界区在任何时间只允许线程串行通过，这和我们使用多线程的初衷是相反的。如果在多线程程序中大量使用 synchronized，或者不适当的使用它，会造成大量线程在临界区的入口等待，造成系统的性能大幅下降。如果在 Thread Dump 中发现这个情况，应该审视源码并对其进行改进。

（2）”Wait Set”里面的线程

当线程获得了 Monitor，进入了临界区之后，如果发现线程继续运行的条件没有满足，它则调用对象（通常是被 synchronized 的对象）的 wait()方法，放弃 Monitor，进入 “Wait Set”队列。只有当别的线程在该对象上调用了 notify()或者 notifyAll()方法，”Wait Set”队列中的线程才得到机会去竞争，但是只有一个线程获得对象的 Monitor，恢复到运行态。”Wait Set”中的线程在 Thread Dump 中显示的状态为 in Object.wait()。通常来说，当 CPU 很忙的时候关注 Runnable 状态的线程，反之则关注 waiting for monitor entry 状态的线程。

jstack 使用示例

找出某 Java 进程中最耗费 CPU 的 Java 线程

（1）找出 Java 进程

假设应用名称为 myapp：

1 2	$ jps \| grep myapp 29527 myapp.jar

得到进程 ID 为 21711

（2）找出该进程内最耗费 CPU 的线程，可以使用 ps -Lfp pid 或者 ps -mp pid -o THREAD, tid, time 或者 top -Hp pid

TIME 列就是各个 Java 线程耗费的 CPU 时间，CPU 时间最长的是线程 ID 为 21742 的线程，用

1	printf "%x\n" 21742

得到 21742 的十六进制值为 54ee，下面会用到。

（3）使用 jstack 打印线程堆栈信息

下一步终于轮到 jstack 上场了，它用来输出进程 21711 的堆栈信息，然后根据线程 ID 的十六进制值 grep，如下：

1 2	$ jstack 21711 \| grep 54ee "PollIntervalRetrySchedulerThread" prio=10 tid=0x00007f950043e000 nid=0x54ee in Object.wait() [0x00007f94c6eda000]

可以看到 CPU 消耗在 PollIntervalRetrySchedulerThread 这个类的 Object.wait()。

注：上面的例子中，默认只显示了一行信息，但很多时候我们希望查看更详细的调用栈。可以通过指定 -A <num> 的方式来显示行数。例如：jstack -l <pid> | grep <thread-hex-id> -A 10

（4）分析代码

我找了下我的代码，定位到下面的代码：

// Idle wait
getLog().info("Thread [" + getName() + "] is idle waiting...");
schedulerThreadState = PollTaskSchedulerThreadState.IdleWaiting;
long now = System.currentTimeMillis();
long waitTime = now + getIdleWaitTime();
long timeUntilContinue = waitTime - now;
synchronized(sigLock) {
	try {
    	if(!halted.get()) {
    		sigLock.wait(timeUntilContinue);
    	}
    }
	catch (InterruptedException ignore) {
    }
}

它是轮询任务的空闲等待代码，上面的 sigLock.wait(timeUntilContinue) 就对应了前面的 Object.wait()。

生成 threaddump 文件

可以使用 jstack -l <pid> > <file-path> 命令生成 threaddump 文件

【示例】生成进程 ID 为 8841 的 Java 进程的 threaddump 文件。

1	jstack -l 8841 > /home/threaddump.txt

jinfo

jinfo(JVM Configuration info)，是 Java 配置信息工具。jinfo 用于实时查看和调整虚拟机运行参数。如传递给 Java 虚拟机的-X（即输出中的 jvm_args）、-XX参数（即输出中的 VM Flags），以及可在 Java 层面通过System.getProperty获取的-D参数（即输出中的 System Properties）。

之前的 jps -v 口令只能查看到显示指定的参数，如果想要查看未被显示指定的参数的值就要使用 jinfo 口令。

jinfo 命令格式：

1	jinfo [option] pid

option 选项参数：

-flag - 输出指定 args 参数的值
-sysprops - 输出系统属性，等同于 System.getProperties()

【示例】jinfo 使用示例

$ jinfo -sysprops 29527
Attaching to process ID 29527, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.222-b10
...

jhat

jhat(JVM Heap Analysis Tool)，是虚拟机堆转储快照分析工具。jhat 与 jmap 搭配使用，用来分析 jmap 生成的 dump 文件。jhat 内置了一个微型的 HTTP/HTML 服务器，生成 dump 的分析结果后，可以在浏览器中查看。

注意：一般不会直接在服务器上进行分析，因为 jhat 是一个耗时并且耗费硬件资源的过程，一般把服务器生成的 dump 文件，用 jvisualvm 、Eclipse Memory Analyzer、IBM HeapAnalyzer 等工具来分析。

命令格式：

1	jhat [dumpfile]

参考资料

Java 故障诊断

发表于 2020-07-30 更新于 2024-01-27 分类于 Java ， JavaSE ， JVM 本文字数： 9.5k 阅读时长 ≈ 9 分钟

Java 故障诊断

故障定位思路

Java 应用出现线上故障，如何进行诊断？

我们在定位线上问题时要有一个整体的思路，顺藤摸瓜，才能较快的找到问题原因。

一般来说，服务器故障诊断的整体思路如下：

应用故障诊断思路：

CPU 问题

一、CPU 使用率过高：往往是由于程序逻辑问题导致的。常见导致 CPU 飙升的问题场景如：死循环，无限递归、频繁 GC、线程上下文切换过多。

二、CPU 始终升不上去：往往是由于程序中存在大量 IO 操作并且时间很长（数据库读写、日志等）。

查找 CPU 占用率较高的进程、线程

线上环境的 Java 应用可能有多个进程、线程，所以，要先找到 CPU 占用率较高的进程、线程。

（1）使用 ps 命令查看 xxx 应用的进程 ID（PID）

1	ps -ef \| grep xxx

也可以使用 jps 命令来查看。

（2）如果应用有多个进程，可以用 top 命令查看哪个占用 CPU 较高。

（3）用 top -Hp pid 来找到 CPU 使用率比较高的一些线程。

（4）将占用 CPU 最高的 PID 转换为 16 进制，使用 printf '%x\n' pid 得到 nid

（5）使用 jstack pic | grep 'nid' -C5 命令，查看堆栈信息：

$ jstack 7129 | grep '0x1c23' -C5
        at java.lang.Object.wait(Object.java:502)
        at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
        - locked <0x00000000b5383ff0> (a java.lang.ref.Reference$Lock)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

"main" #1 prio=5 os_prio=0 tid=0x00007f4df400a800 nid=0x1c23 in Object.wait() [0x00007f4dfdec8000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000b5384018> (a org.apache.felix.framework.util.ThreadGate)
        at org.apache.felix.framework.util.ThreadGate.await(ThreadGate.java:79)
        - locked <0x00000000b5384018> (a org.apache.felix.framework.util.ThreadGate)

（6）更常见的操作是用 jstack 生成堆栈快照，然后基于快照文件进行分析。生成快照命令：

1	jstack -F -l pid >> threaddump.log

（7）分析堆栈信息

一般来说，状态为 WAITING、TIMED_WAITING 、BLOCKED 的线程更可能出现问题。可以执行以下命令查看线程状态统计：

1	cat threaddump.log \| grep "java.lang.Thread.State" \| sort -nr \| uniq -c

如果存在大量 WAITING、TIMED_WAITING 、BLOCKED ，那么多半是有问题啦。

是否存在频繁 GC

如果应用频繁 GC，也可能导致 CPU 飙升。为何频繁 GC 可以使用 jstack 来分析问题（分析和解决频繁 GC 问题，在后续讲解）。

那么，如何判断 Java 进程 GC 是否频繁？

可以使用 jstat -gc pid 1000 命令来观察 GC 状态。

$ jstat -gc 29527 200 5
 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT
22528.0 22016.0  0.0   21388.2 4106752.0 921244.7 5592576.0  2086826.5  110716.0 103441.1 12416.0 11167.7   3189   90.057  10      2.140   92.197
22528.0 22016.0  0.0   21388.2 4106752.0 921244.7 5592576.0  2086826.5  110716.0 103441.1 12416.0 11167.7   3189   90.057  10      2.140   92.197
22528.0 22016.0  0.0   21388.2 4106752.0 921244.7 5592576.0  2086826.5  110716.0 103441.1 12416.0 11167.7   3189   90.057  10      2.140   92.197
22528.0 22016.0  0.0   21388.2 4106752.0 921244.7 5592576.0  2086826.5  110716.0 103441.1 12416.0 11167.7   3189   90.057  10      2.140   92.197
22528.0 22016.0  0.0   21388.2 4106752.0 921244.7 5592576.0  2086826.5  110716.0 103441.1 12416.0 11167.7   3189   90.057  10      2.140   92.197

是否存在频繁上下文切换

针对频繁上下文切换问题，可以使用 vmstat pid 命令来进行查看。

$ vmstat 7129
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0   6836 737532   1588 3504956    0    0     1     4    5    3  0  0 100  0  0

其中，cs 一列代表了上下文切换的次数。

【解决方法】

如果，线程上下文切换很频繁，可以考虑在应用中针对线程进行优化，方法有：

无锁并发：多线程竞争时，会引起上下文切换，所以多线程处理数据时，可以用一些办法来避免使用锁，如将数据的 ID 按照 Hash 取模分段，不同的线程处理不同段的数据；
CAS 算法：Java 的 Atomic 包使用 CAS 算法来更新数据，而不需要加锁；
最少线程：避免创建不需要的线程，比如任务很少，但是创建了很多线程来处理，这样会造成大量线程都处于等待状态；
使用协程：在单线程里实现多任务的调度，并在单线程里维持多个任务间的切换；

内存问题

内存问题诊断起来相对比 CPU 麻烦一些，场景也比较多。主要包括 OOM、GC 问题和堆外内存。一般来讲，我们会先用 free 命令先来检查一发内存的各种情况。

诊断内存问题，一般首先会用 free 命令查看一下机器的物理内存使用情况。

$ free
              total        used        free      shared  buff/cache   available
Mem:        8011164     3767900      735364        8804     3507900     3898568
Swap:       5242876        6836     5236040

磁盘问题

查看磁盘空间使用率

可以使用 df -hl 命令查看磁盘空间使用率。

$ df -hl
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        494M     0  494M   0% /dev
tmpfs           504M     0  504M   0% /dev/shm
tmpfs           504M   58M  447M  12% /run
tmpfs           504M     0  504M   0% /sys/fs/cgroup
/dev/sda2        20G  5.7G   13G  31% /
/dev/sda1       380M  142M  218M  40% /boot
tmpfs           101M     0  101M   0% /run/user/0

查看磁盘读写性能

可以使用 iostat 命令查看磁盘读写性能。

iostat -d -k -x
Linux 3.10.0-327.el7.x86_64 (elk-server)        03/07/2020      _x86_64_        (4 CPU)

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.14    0.01    1.63     0.42   157.56   193.02     0.00    2.52   11.43    2.48   0.60   0.10
scd0              0.00     0.00    0.00    0.00     0.00     0.00     8.00     0.00    0.27    0.27    0.00   0.27   0.00
dm-0              0.00     0.00    0.01    1.78     0.41   157.56   177.19     0.00    2.46   12.09    2.42   0.59   0.10
dm-1              0.00     0.00    0.00    0.00     0.00     0.00    16.95     0.00    1.04    1.04    0.00   1.02   0.00

查看具体的文件读写情况

可以使用 lsof -p pid 命令

网络问题

无法连接

可以通过 ping 命令，查看是否能连通。

通过 netstat -nlp | grep <port> 命令，查看服务端口是否在工作。

网络超时

网络超时问题大部分出在应用层面。超时大体可以分为连接超时和读写超时，某些使用连接池的客户端框架还会存在获取连接超时和空闲连接清理超时。

读写超时。readTimeout/writeTimeout，有些框架叫做 so_timeout 或者 socketTimeout，均指的是数据读写超时。注意这边的超时大部分是指逻辑上的超时。soa 的超时指的也是读超时。读写超时一般都只针对客户端设置。
连接超时。connectionTimeout，客户端通常指与服务端建立连接的最大时间。服务端这边 connectionTimeout 就有些五花八门了，jetty 中表示空闲连接清理时间，tomcat 则表示连接维持的最大时间。
其他。包括连接获取超时 connectionAcquireTimeout 和空闲连接清理超时 idleConnectionTimeout。多用于使用连接池或队列的客户端或服务端框架。

我们在设置各种超时时间中，需要确认的是尽量保持客户端的超时小于服务端的超时，以保证连接正常结束。

在实际开发中，我们关心最多的应该是接口的读写超时了。

如何设置合理的接口超时是一个问题。如果接口超时设置的过长，那么有可能会过多地占用服务端的 tcp 连接。而如果接口设置的过短，那么接口超时就会非常频繁。

服务端接口明明 rt 降低，但客户端仍然一直超时又是另一个问题。这个问题其实很简单，客户端到服务端的链路包括网络传输、排队以及服务处理等，每一个环节都可能是耗时的原因。

TCP 队列溢出

tcp 队列溢出是个相对底层的错误，它可能会造成超时、rst 等更表层的错误。因此错误也更隐蔽，所以我们单独说一说。

如上图所示，这里有两个队列：syns queue(半连接队列）、accept queue（全连接队列）。三次握手，在 server 收到 client 的 syn 后，把消息放到 syns queue，回复 syn+ack 给 client，server 收到 client 的 ack，如果这时 accept queue 没满，那就从 syns queue 拿出暂存的信息放入 accept queue 中，否则按 tcp_abort_on_overflow 指示的执行。

tcp_abort_on_overflow 0 表示如果三次握手第三步的时候 accept queue 满了那么 server 扔掉 client 发过来的 ack。tcp_abort_on_overflow 1 则表示第三步的时候如果全连接队列满了，server 发送一个 rst 包给 client，表示废掉这个握手过程和这个连接，意味着日志里可能会有很多connection reset / connection reset by peer。

那么在实际开发中，我们怎么能快速定位到 tcp 队列溢出呢？

netstat 命令，执行 netstat -s | egrep “listen|LISTEN”

如上图所示，overflowed 表示全连接队列溢出的次数，sockets dropped 表示半连接队列溢出的次数。

ss 命令，执行 ss -lnt

上面看到 Send-Q 表示第三列的 listen 端口上的全连接队列最大为 5，第一列 Recv-Q 为全连接队列当前使用了多少。

接着我们看看怎么设置全连接、半连接队列大小吧：

全连接队列的大小取决于 min(backlog, somaxconn)。backlog 是在 socket 创建的时候传入的，somaxconn 是一个 os 级别的系统参数。而半连接队列的大小取决于 max(64, /proc/sys/net/ipv4/tcp_max_syn_backlog)。

在日常开发中，我们往往使用 servlet 容器作为服务端，所以我们有时候也需要关注容器的连接队列大小。在 tomcat 中 backlog 叫做acceptCount，在 jetty 里面则是acceptQueueSize。

RST 异常

RST 包表示连接重置，用于关闭一些无用的连接，通常表示异常关闭，区别于四次挥手。

在实际开发中，我们往往会看到connection reset / connection reset by peer错误，这种情况就是 RST 包导致的。

端口不存在

如果像不存在的端口发出建立连接 SYN 请求，那么服务端发现自己并没有这个端口则会直接返回一个 RST 报文，用于中断连接。

主动代替 FIN 终止连接

一般来说，正常的连接关闭都是需要通过 FIN 报文实现，然而我们也可以用 RST 报文来代替 FIN，表示直接终止连接。实际开发中，可设置 SO_LINGER 数值来控制，这种往往是故意的，来跳过 TIMED_WAIT，提供交互效率，不闲就慎用。

客户端或服务端有一边发生了异常，该方向对端发送 RST 以告知关闭连接

我们上面讲的 tcp 队列溢出发送 RST 包其实也是属于这一种。这种往往是由于某些原因，一方无法再能正常处理请求连接了(比如程序崩了，队列满了)，从而告知另一方关闭连接。

接收到的 TCP 报文不在已知的 TCP 连接内

比如，一方机器由于网络实在太差 TCP 报文失踪了，另一方关闭了该连接，然后过了许久收到了之前失踪的 TCP 报文，但由于对应的 TCP 连接已不存在，那么会直接发一个 RST 包以便开启新的连接。

一方长期未收到另一方的确认报文，在一定时间或重传次数后发出 RST 报文

这种大多也和网络环境相关了，网络环境差可能会导致更多的 RST 报文。

之前说过 RST 报文多会导致程序报错，在一个已关闭的连接上读操作会报connection reset，而在一个已关闭的连接上写操作则会报connection reset by peer。通常我们可能还会看到broken pipe错误，这是管道层面的错误，表示对已关闭的管道进行读写，往往是在收到 RST，报出connection reset错后继续读写数据报的错，这个在 glibc 源码注释中也有介绍。

我们在诊断故障时候怎么确定有 RST 包的存在呢？当然是使用 tcpdump 命令进行抓包，并使用 wireshark 进行简单分析了。tcpdump -i en0 tcp -w xxx.cap，en0 表示监听的网卡。

接下来我们通过 wireshark 打开抓到的包，可能就能看到如下图所示，红色的就表示 RST 包了。

TIME_WAIT 和 CLOSE_WAIT

TIME_WAIT 和 CLOSE_WAIT 是啥意思相信大家都知道。
在线上时，我们可以直接用命令netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'来查看 time-wait 和 close_wait 的数量

用 ss 命令会更快ss -ant | awk '{++S[$1]} END {for(a in S) print a, S[a]}'

TIME_WAIT

time_wait 的存在一是为了丢失的数据包被后面连接复用，二是为了在 2MSL 的时间范围内正常关闭连接。它的存在其实会大大减少 RST 包的出现。

过多的 time_wait 在短连接频繁的场景比较容易出现。这种情况可以在服务端做一些内核参数调优:

#表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭
net.ipv4.tcp_tw_reuse = 1
#表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭
net.ipv4.tcp_tw_recycle = 1

当然我们不要忘记在 NAT 环境下因为时间戳错乱导致数据包被拒绝的坑了，另外的办法就是改小tcp_max_tw_buckets，超过这个数的 time_wait 都会被干掉，不过这也会导致报time wait bucket table overflow的错。

CLOSE_WAIT

close_wait 往往都是因为应用程序写的有问题，没有在 ACK 后再次发起 FIN 报文。close_wait 出现的概率甚至比 time_wait 要更高，后果也更严重。往往是由于某个地方阻塞住了，没有正常关闭连接，从而渐渐地消耗完所有的线程。

想要定位这类问题，最好是通过 jstack 来分析线程堆栈来诊断问题，具体可参考上述章节。这里仅举一个例子。

开发同学说应用上线后 CLOSE_WAIT 就一直增多，直到挂掉为止，jstack 后找到比较可疑的堆栈是大部分线程都卡在了countdownlatch.await方法，找开发同学了解后得知使用了多线程但是确没有 catch 异常，修改后发现异常仅仅是最简单的升级 sdk 后常出现的class not found。

GC 问题

GC 问题除了影响 CPU 也会影响内存，诊断思路也是一致的。

（1）通常，先使用 jstat 来查看分代变化情况，比如 minor gc 或 full gc 次数是不是太频繁、耗时太久。

线程量太大，且不被及时 GC 也会引发 OOM，大部分就是之前说的 unable to create new native thread。除了 jstack 细细分析 dump 文件外，我们一般先会看下总体线程。

可以执行以下命令中任意一个，没来查看当前进程创建的总线程数。

1 2	pstreee -p pid \| wc -l ls -l /proc/pid/task \| wc -l

堆内内存泄漏总是和 GC 异常相伴。不过 GC 问题不只是和内存问题相关，还有可能引起 CPU 负载、网络问题等系列并发症，只是相对来说和内存联系紧密些，所以我们在此单独总结一下 GC 相关问题。

我们在 cpu 章介绍了使用 jstat 来获取当前 GC 分代变化信息。而更多时候，我们是通过 GC 日志来诊断问题的，在启动参数中加上-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps来开启 GC 日志。
常见的 Minor GC、Full GC 日志含义在此就不做赘述了。

针对 gc 日志，我们就能大致推断出 Minor GC 与 fullGC 是否过于频繁或者耗时过长，从而对症下药。我们下面将对 G1 垃圾收集器来做分析，这边也建议大家使用 G1-XX:+UseG1GC。

OOM

查看 GC 日志，如果有明显提示 OOM 问题，那就可以根据提示信息，较为快速的定位问题。

OOM 定位可以参考：JVM 内存区域之 OutOfMemoryError

Minor GC

Minor GC 过频

Minor GC 频繁一般是短周期的 Java 小对象较多。

（1）先考虑是不是 Eden 区/新生代设置的太小了，看能否通过调整 -Xmn、-XX:SurvivorRatio 等参数设置来解决问题。

（2）如果参数正常，但是 Minor GC 频率还是太高，就需要使用 jmap 和 MAT 对 dump 文件进行进一步诊断了。

Minor GC 耗时过长

Minor GC 耗时过长问题就要看 GC 日志里耗时耗在哪一块了。

以 G1 GC 日志为例，可以关注 Root Scanning、Object Copy、Ref Proc 等阶段。Ref Proc 耗时长，就要注意引用相关的对象。Root Scanning 耗时长，就要注意线程数、跨代引用。Object Copy 则需要关注对象生存周期。而且耗时分析它需要横向比较，就是和其他项目或者正常时间段的耗时比较。

Full GC 过频

G1 中更多的还是 mixedGC，但 mixedGC 可以和 Minor GC 思路一样去诊断。触发 fullGC 了一般都会有问题，G1 会退化使用 Serial 收集器来完成垃圾的清理工作，暂停时长达到秒级别，可以说是半跪了。

fullGC 的原因可能包括以下这些，以及参数调整方面的一些思路：

并发阶段失败：在并发标记阶段，MixGC 之前老年代就被填满了，那么这时候 G1 就会放弃标记周期。这种情况，可能就需要增加堆大小，或者调整并发标记线程数-XX:ConcGCThreads。
晋升失败：在 GC 的时候没有足够的内存供存活/晋升对象使用，所以触发了 Full GC。这时候可以通过-XX:G1ReservePercent来增加预留内存百分比，减少-XX:InitiatingHeapOccupancyPercent来提前启动标记，-XX:ConcGCThreads来增加标记线程数也是可以的。
大对象分配失败：大对象找不到合适的 region 空间进行分配，就会进行 fullGC，这种情况下可以增大内存或者增大-XX:G1HeapRegionSize。
程序主动执行 System.gc()：不要随便写就对了。

另外，我们可以在启动参数中配置-XX:HeapDumpPath=/xxx/dump.hprof来 dump fullGC 相关的文件，并通过 jinfo 来进行 gc 前后的 dump

1 2	jinfo -flag +HeapDumpBeforeFullGC pid jinfo -flag +HeapDumpAfterFullGC pid

这样得到 2 份 dump 文件，对比后主要关注被 gc 掉的问题对象来定位问题。

常用 Linux 命令

在故障排查时，有一些 Linux 命令十分有用，建议掌握。

top

top 命令可以实时动态地查看系统的整体运行情况，是一个综合了多方信息监测系统性能和运行信息的实用工具。

通常，会使用 top -Hp pid 查看具体线程使用系统资源情况。

命令详情参考：http://man.linuxde.net/top

vmstat

vmstat 是一款指定采样周期和次数的功能性监测工具，我们可以看到，它不仅可以统计内存的使用情况，还可以观测到 CPU 的使用率、swap 的使用情况。但 vmstat 一般很少用来查看内存的使用情况，而是经常被用来观察进程的上下文切换。

r：等待运行的进程数；
b：处于非中断睡眠状态的进程数；
swpd：虚拟内存使用情况；
free：空闲的内存；
buff：用来作为缓冲的内存数；
si：从磁盘交换到内存的交换页数量；
so：从内存交换到磁盘的交换页数量；
bi：发送到块设备的块数；
bo：从块设备接收到的块数；
in：每秒中断数；
cs：每秒上下文切换次数；
us：用户 CPU 使用时间；
sy：内核 CPU 系统使用时间；
id：空闲时间；
wa：等待 I/O 时间；
st：运行虚拟机窃取的时间。

JavaWeb 之 Cookie 和 Session

Cookie

Cookie 是什么

Cookie 剖析

Cookie 类中的方法

Cookie 的有效期

Cookie 的域名

Cookie 的路径

Cookie 的安全属性

Cookie 实例

添加 Cookie

显示 Cookie

删除 Cookie

Session

Session 是什么

Session 类中的方法

Session 的有效期

Session 对浏览器的要求

URL 地址重写

Session 中禁用 Cookie

Session 实例

Session 跟踪

删除 Session 会话数据

Cookie vs Session

存取方式

隐私安全

有效期

服务器的开销

浏览器的支持

跨域名

错误处理

错误的分类

资源的错误

程序的错误

用户的错误

错误返回码和异常捕捉

异步编程的错误处理

callback 错误处理

JavaScript 的 Promise 错误处理

Java 的 Promise 模式

错误处理的最佳实践

SpringBoot 基本原理

SpringBootApplication 背后的秘密

@Configuration

@ComponentScan

@EnableAutoConfiguration

AutoConfigurationPackage 注解：

Import(AutoConfigurationImportSelector.class)注解：

自动配置幕后英雄：SpringFactoriesLoader 详解

参考资料

SpringBoot 知识图谱

一、抛砖引玉：探索 Spring IoC 容器

1.1、Spring IoC 容器

1.2、Spring 容器扩展机制

二、夯实基础：JavaConfig 与常见 Annotation

2.1、JavaConfig

2.2、@ComponentScan

2.3、@Import

2.4、@Conditional

2.5、@ConfigurationProperties 与@EnableConfigurationProperties

三、削铁如泥：SpringFactoriesLoader 详解

四、另一件武器：Spring 容器的事件监听机制

Spring 容器内的事件监听机制

五、出神入化：揭秘自动配置原理

六、启动引导：Spring Boot 应用启动的秘密

6.1 SpringApplication 初始化

6.2 Spring Boot 启动流程

参考资料

领域驱动设计简介

DDD 简介

软件架构模式的演进

什么是 DDD

DDD 与微服务的关系

DDD 核心概念

域

通用语言和上下文边界

实体和值对象

聚合和聚合跟

聚合设计步骤

聚合设计原则