秒杀其他按键精灵

@Bean 默 认 会 将 方 法 thymeleafViewResolver 作 为 Bean 的 key, 将 返 回 的Thymeleaf-ViewResolver 对 象 作 为 Value 存 入 容 器 当 中 。 在 方 法 内 部 ， 可 通 过ThymeleafViewResolver 对应的方法进行属性的初始化设置。通过以上代码我们便完成了自定义 Thymeleaf-ViewResolver 的注入。

那么，原来默认的 ThymeleafViewResolver 会怎么处理呢? 我们知道几乎所有的自动配置类都是通过注解设置初始化条件的，比如 ThymeleafViewResolver 默认实例化的条件是当容器中不存在名称为 thymeleafViewResolver 时才会使用默认的初始化。当自定义的ThymeleafViewResolver 类完成初始化之后，默认配置的初始化条件便不再满足了。

上面针对 SpringMVC 中 Thymeleaf 的 ViewResolver 的自定义进行了讲解。

其实在 Spring Boot 中，大多数组件都可以采用同样的方式对默认配置进行覆盖。除了上述方法，在 Spring Boot 项目中还可以通过实现 WebMvcConfigurer 接口来进行更灵活地自定义配置。

通过 WebMvcConfigurer 接口实现自定义配置是 Spring 内部的一-种配置方式，它替代了传统的 XML 形式的配置。通过对该接口具体方法的实现，可以自定义一些 Handler、Interceptor 、ViewResolver 、MessageConverter 等参 数 。 以 上 面 配 置ThymeleafViewResolver 为例，我们也可以通过实现该接口的 configureViewResolvers 方法来进行配置,达到同样的效果，具体示例代码如下：
 

通过前面的学习我们已经得知引入该 starter 之后，Spring Boot 便会进行一个初始化的基本配置，因此针对 Thymeleaf 的最简单集成便完成了，关于页面展示和基础配置我们暂时先不考虑。当集成 Thymeleaf 之后，Thymeleaf 对应的自动配置类 ThymeleafAutoConfiguration 中会初始化一个 ThymeleafViewResolver, 用来对 Thymeleaf 的页面进行解析和渲染。这一操作本质上同默认的 BeanNameViewResolver 作用-样，都实现了 ViewResolver 接口。

此时，如果官方提供的 ThymeleafViewResolver 的默认设 置无法满足我们的需求，可以通过 两 种 途 径 进 行 自 定 义 设 置 : 通 过 application 配 置 文 件 配 置 和 自 行 创 建ThymeleafViewResolver 对象。

通过 application 配置对应的属性定义位于 ThymeleafProperties 类中，我们已经做过多次类似的配置，不再赘述。

我们可以通过以下方式自行创建 ThymeleafViewResolver 对象。先定义一个配置类ViewResolverConfig，并在类内部通过@Bean 注解对实例化的 ThymeleafViewResolver对象进行注入容器的操作。
 

综合实战

关于 Web 方面的配置比较多，值得庆幸的是，Spring Boot 已经帮我们预置初始化了很多基础组件。但在实践的过程中，某些基础的组件并不能满足我们的实际需求,这时就需要我们重新初始化相应组件，甚至在某些极端的情况下需要完全接管 Spring Boot 的默认配置。

本文将基于对前端模板框架 Thymeleaf 的集成，逐步向大家演示如何自定义 ViewResolver以及如何进一步 扩展 Spring MVC 配置。本实例涉及集成 Thymeleaf、自定义初始化ThymeleafViewResolver 以及扩展 Spring MVC。
 

可以看到，文件相关内存(Active(file) + Inactive(file) )达到了32.49GB，脏数据达到7.09GB。脏数据量比预期要少，远没达到dirty_background_ratio和dirty_ratio设置的阈值。因此，如果需要缓存更多的写数据，只能延长定时唤醒回刷的时间dirty_writeback_centisecs。这个服务器主要用于编译SDK，读的需求远大于写，因此缓存更多的脏数据没太大意义。

我还发现Buffers达到了12G，应该是ext4的inode占用了大量的缓存。如上分析的，此服务器的ext4有大量富余的inode，在缓存的元数据里，无效的inode不知道占比多少。减少inode数量，提高inode利用率，说不定可以提高inode预读的命中率。

优化后，一次使能8个SDK并行编译，走完一次完整的编译流程(包括更新代码，抓取提交，编译内核，编译SDK等)，在没有进入错误处理流程的情况下，用时大概13分钟。

这次的优化就到这里结束了，等后期使用过程如果还有问题再做调整。

（编辑：济源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!