1. server.compression.enabled: 默认为  false
2. server.compression.excluded-user-agents: 针对哪些 user-agents(逗号分隔) 不压缩，默认为空
3. server.compression.mime-types: 会对哪些响应的 content-type 进行压缩，默认为 text/html, text/xml, text/plain, text/css, text/javascript, application/javascript, application/json, application/xml
4. server.compression.min-response-size: 默认为 2KB

1. SpringBoot 2.7.17, SpringWeb 项目，所引用入的 spring-webmvc-5.3.30, spring 6 已解决
2. JDK 1.8 或 JDK 17
3. 依赖了 jackson-dataformat-xml:2.12.6 和 jackson-dataformat-cbor:2.12.6, 它会在 RestTemplate 加上 application/xml, application/cbor 等 Accept 类型
4. 代码中用 RestTemplate 调用此应用的 Endpoint, 未设置任何头

restTemplate.getForEntity("http://localhost:8080/test2", String.class)

1. 默认选择 Cache
2. 声明 Spring Bean Cache
3. 声明 Spring Bean CacheManager
4. 通过 spring.cache.type 属性选择
5. 引入相应的 Cache 实现依赖

Java 1.5(Tiger) 个人认为最为激动人心的两个特性是泛型与注解(Java Versions, Features and History)。泛型自然是不必说了，注解对 Java 世界的改变比泛型伟大的多(现在框架的注解配置)，在 Java 1.5 之前我们只能在 Javadoc 注释中做文章，于是只能用 XDoclet 那样不伦不类的东西。Java 的注解发展到现在几乎可以使用在书写代码时的任何地方，见 java.lang.annotation.ElementType 中的类型，囊括了 TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE, ANNOTATION_TYPE, PACKAGE, TYPE_PARAMETER(since 1.8), TYPE_USE(since 1.8)。

Java 1.5 基本确定了注解的基本框架，包括元注解(meta-annotation); 直到 Java 8 又扩展了注解的使用范围，列举如下：

创建类实例

new@Interned MyObject();

类型映射

myString = (@NonNull String) str;

implements 语句中

class UnmodifiableList<T> implements@Readonly List<@Readonly T> { ... }

throw exception声明

void monitorTemperature() throws@Critical TemperatureException { ... }

解析前面 ElementType Java 8 增加的 TYPE_PARAMETER和 TYPE_USE 注解使用新场合。ElementType.TYPE_PARAMETER 表示该注解能写在类型变量的声明语句中。ElementType.TYPE_USE 表示该注解能写在使用类型的任何语句中(如: 声明语句、泛型和强制转换语句中的类型) Read More

在 Spring 中应用 ServiceLocator 方式来获取 Spring Bean 的介绍参考了那么多，其实还是数官方的 ServiceLocatorFactoryBean JavaDoc 文档最言简意该了。Spring 的 ServiceLocator 仿佛用处不大，说到底就是类似于下方找寻某个 Spring Bean 一样：

ApplicationContext context = ...; Service service = context.getBean(ServiceImpl.class); Service service = context.getBean("myService");

只是有了 ServiceLocatorFactoryBean(它本质上就是一个 FactoryBean) 后我们不需要直接与 ApplicationContext 打交道，且多个的 Spring Bean 可以从相关的一个 FactoryBean 获得。下面用两个例子来演示(代码中刨去了 package 和 import 部分的代码)

一：实现类只有一个 Spring Bean 时

接口类 Parser(我们要定位就是它的实现类) Read More

Spring 相关代码分析

1@SpringBootApplication
2@ComponentScan(basePackages = "cc.unmi")
3public class DemoApplication {
4    public static void main(String[] args) {
5        SpringApplication.run(DemoApplication.class, args);
6    }
7}

用过  Spring 的 @EnableScheduling 的都知道，我们用三种形式来部署计划任务，即 @Scheduled 注解的 fixedRate(fixedRateString), fixedDelay(fixedDelayString), 以及 cron. cron 不在这里讨论的范畴。我们着重在如何理解 fixedRate 和 fixedDelay 的区别。

在 Spring 的  Scheduled 注解的 JavaDoc 对此的解释很简单

public abstract long fixedRate
Execute the annotated method with a fixed period in milliseconds between invocations.

public abstract long fixedDelay
Execute the annotated method with a fixed period in milliseconds between the end of the last invocation and the start of the next.

只是说是 fixedRate 任务两次执行时间间隔是任务的开始点，而 fixedDelay 的间隔是前次任务的结束与下次任务的开始。

大致用示意字符串来表示如下(每个 T1, 或 T2 代表任务执行秒数(每次任务执行时间不定)，假定 fixedRate 或  fixedDelay 的值是 5 秒，用 W 表示等待的数)

fixedRate:    T1.T1WWWT2.T2.T2WW.T3.T3.T3.T3.T3.T4.T4.T4.T4.T4.T4.T4T5T5WWWT6.T6........

fixedDelay:  T1.T1.WWWWW.T2.T2.T2WWWWW.T3.T3.T3.T3.T3.WWWWW.T4.T4.T4.T4.T4.T4.T4.WWWWWT6.T6......

一般来说能理解到上面两个场景已经差不多了，相比而言 fixedDelay 简单些，盯着上一次任务的屁股就行。 Read More

--!select.user
select id, firstname, lastname, address --!update.user
update ........

@PropertySource(value = "classpath:sql/queries.sql", factory = SqlPropertySourceFactory.class)

@SqlPropertySource("classpath:sql/queries.sql")