如下图，有7个节点，其中A为起始节点，G为终止节点，节点与节点之间使用边进行连接，每条边上都有一个数字表示这个边的权重，现在需要求出从A到G权重之和最短的路径。

如果这个图中每条边都等价，即没有权重，那计算路径就非常简单，直接使用广度优先遍历即可得出最短路径为 A-B-E-G，但现在边上增加了权重，广度优先遍历出来的最短路径权重之和为29，而另外一条路线 A-C-D-E-G 的权重之和却只有24，显然新的这条路径更优。

那问题来了，在这种加权图中，怎么找到最短路径呢？答案就是迪杰斯特拉算法(Dijkstra Algorithm)。

Spring Web MVC是基于Servlet API构建的原始Web框架，从一开始就已包含在Spring框架中。 正式名称“Spring Web MVC”来自其源模块的名称（spring-webmvc），但它通常被称为“Spring MVC”。

与其他许多Web框架一样，Spring MVC围绕前端控制器模式进行设计，在该模式下，DispatcherServlet作为中央Servlet提供了用于请求处理的共享算法，而实际工作是由可配置的委托组件执行的。该模型非常灵活，并支持多种工作流程。

SpringBoot 的配置加载主要通过事件广播机制来完成，即由 SpringApplication 启动过程中，通过调用 SpringApplicationRunListener.environmentPrepared() 触发 ConfigFileApplicationListener 对 ApplicationEvent 事件的响应。

由于本文主要分析配置加载的流程，对于启动过程中的事件传播不做过多的介绍，直接从 ConfigFileApplicationListener 开始学习具体的配置加载流程。

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

@Override
public void onApplicationEvent(ApplicationEvent event) {
    if (event instanceof ApplicationEnvironmentPreparedEvent) {
        onApplicationEnvironmentPreparedEvent((ApplicationEnvironmentPreparedEvent) event);
    }
    if (event instanceof ApplicationPreparedEvent) {
        onApplicationPreparedEvent(event);
    }
}

private void onApplicationEnvironmentPreparedEvent(ApplicationEnvironmentPreparedEvent event) {
    List<EnvironmentPostProcessor> postProcessors = loadPostProcessors();
    // 将其自身添加到 EnvironmentPostProcessor 列表，用于处理配置文件的加载
    postProcessors.add(this);
    AnnotationAwareOrderComparator.sort(postProcessors);
    for (EnvironmentPostProcessor postProcessor : postProcessors) {
        postProcessor.postProcessEnvironment(event.getEnvironment(), event.getSpringApplication());
    }
}

大多数情况下，我们都可以在 main() 方法中调用 SpringApplication.run() 引导启动一个SpringBoot应用。

1
2
3
4
5
6

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

默认情况下，SpringApplication 将执行以下步骤来引导应用程序：

• 根据 classpath 创建一个合适的 ApplicationContext 实例
• 注册一个 CommandLinePropertySource 以将命令行参数公开为 Spring 属性
• 刷新应用程序上下文，加载所有单例 Bean
• 触发所有 CommandLineRunner

转自： https://www.ibm.com/developerworks/cn/java/j-lo-classloader/

类加载器是 Java 语言的一个创新，也是 Java 语言流行的重要原因之一。它使得 Java 类可以被动态加载到 Java 虚拟机中并执行。类加载器从 JDK 1.0 就出现了，最初是为了满足 Java Applet 的需要而开发出来的。Java Applet 需要从远程下载 Java 类文件到浏览器中并执行。现在类加载器在 Web 容器和 OSGi 中得到了广泛的使用。一般来说，Java 应用的开发人员不需要直接同类加载器进行交互。Java 虚拟机默认的行为就已经足够满足大多数情况的需求了。不过如果遇到了需要与类加载器进行交互的情况，而对类加载器的机制又不是很了解的话，就很容易花大量的时间去调试 ClassNotFoundException和 NoClassDefFoundError等异常。本文将详细介绍 Java 的类加载器，帮助读者深刻理解 Java 语言中的这个重要概念。下面首先介绍一些相关的基本概念。

转自：https://www.ibm.com/developerworks/cn/java/j-lo-javasecurity/

作为一种诞生于互联网兴起时代的语言，Java 从一开始就带有安全上的考虑，如何保证通过互联网下载到本地的 Java 程序是安全的，如何对 Java 程序访问本地资源权限进行有限授权，这些安全角度的考虑一开始就影响到 Java 语言的设计与实现。可以说 Java 在这些方面的探索与经验，对后来的一些语言与产品都带来了积极影响。

本篇文章中将介绍 Java 中安全模型，以及如何利用安全访问控制机制来实现一些特定目的。

在 Bean生命周期(一) 浅尝知味 中，我们介绍了Bean的生命周期，并通过实验对其进行了验证，这次我们将从源码角度对其做进一步说明。整个Bean的生命周期，主要的逻辑就是实例化、初始化、销毁，而这些逻辑都集中在两个类里面，一个是 AbstractAutowireCapableBeanFactory，负责Bean的实例化与初始化，另外一个是 DisposableBeanAdapter，负责Bean的整个销毁流程。

在Spring体系中，对象的实例（Bean）都是交给Spring容器进行管理的，但是对于Bean在Spring中是创建及销毁流程，很多人都只有一个模糊的概念，今天我们就来认真地探寻一下Bean生命周期的问题。

生命周期图

首先，给大家晒上一张我画的生命周期图，当然这并不是完整的流程，像 InstantiationAwareBeanPostProcessor 里面的 postProcessProperties() 在图上就没有体现，为啥不画呢？

数据库配置

In-Memory 数据库

SpringBoot 可以自动配置嵌入式数据库，如：H2，HSQL 和 Derby 等。不需要提供任何连接URL，只需将构建依赖关系包含到要使用的嵌入式数据库中即可。

以 HSQL 配置 In-Memory 数据库：

1

"org.hsqldb:hsqldb:2.4.0"

使用内存嵌入式数据库开发应用程序通常很方便。显然，内存数据库不提供持久存储；在应用程序启动时，需要填充数据库，并准备在应用程序结束时丢弃数据。

持久化数据库

与 In-Memory 数据库相比，持久化数据库需要配置更多的信息，如：数据库连接地址、用户名、密码等。

以 Mysql 为例，依赖配置项如下：

1

"mysql:mysql-connector-java:6.0.6"

数据库配置项如下：

1
2
3
4
5
6

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/test?useUnicode=true&characterEncoding=UTF-8
    username: root
    password: 123456
    driver-class-name: com.mysql.cj.jdbc.Driver

在本篇文章中不会详细介绍日志如何配置、如果切换另外一种日志工具之类的内容，只用于记录作者本人在工作过程中对日志的几种处理方式。

Debug 日志管理

在开发的过程中，总会遇到各种莫名其妙的问题，而这些问题的定位一般会使用到两种方式，第一种是通过手工 Debug 代码，第二种则是直接查看日志输出。Debug 代码这种方式只能在 IDE 下使用，一旦程序移交部署，就只能通过日志来跟踪定位了。

在测试环境下，我们无法使用 Debug 代码来定位问题，所以这时候需要记录所有请求的参数及对应的响应报文。而在 数据交互篇 中，我们将请求及响应的格式都定义成了Json，而且传输的数据还是存放在请求体里面。而请求体对应在 HttpServletRequest 里面又只是一个输入流，这样的话，就无法在过滤器或者拦截器里面去做日志记录了，而必须要等待输入流转换成请求模型后（响应对象转换成输出流前）做数据日志输出。