皮皮网

1.玩转 Spring Boot 原理篇（自动装配前凑之自定义Stater）
2.数据库连接池之Hikari
3.driver does not support get/ set network timeout for connections错误的源码原因是什么？
4.Hikari源码分析 - AntiDebug
5.wvp-GB28181-pro的安装与调试
6.弹性数据库连接池探活策略调研 (二)——Druid | 京东云技术团队

玩转 Spring Boot 原理篇（自动装配前凑之自定义Stater）

       自动装配在Spring Boot框架中的重要性不言而喻，它简化了开发者的源码工作，使得应用的源码构建更加高效、便捷。源码为了更深入地理解这一原理，源码本文将以自定义Spring Boot Starter的源码歌单卡源码免费方式，从代码层面直观感受自动装配的源码威力。

       在开始之前，源码我们先对历史文章进行整理，源码以确保全面了解Spring Boot的源码集成应用，包括MySQL、源码Druid、源码HikariCP等数据库连接，源码MyBatis、源码JPA和事务支持，源码Redis的集成，Actuator和Spring Boot Admin的使用，RabbitMQ的引入，@Scheduled和静态、动态定时任务的实现，以及任务动态管理代码篇和定时任务框架Quartz。

       接下来，我们将关注Spring Boot自动装配的核心原理，特别是自定义Starter的实现。以mybatis-spring-boot-starter为参考，我们将通过模仿其自动配置机制来构建一个猜数字游戏服务的Starter。

       ### 找到葫芦

       将mybatis-spring-boot-starter作为葫芦参考，观察其在pom文件中的依赖结构和自动配置机制。重点关注其在META-INF/spring.factories文件中的配置，以及自动配置类MybatisAutoConfiguration，如何生成SqlSessionFactory、SqlSessionTemplate等MyBatis实例，跳转题源码并将其注册到Spring容器。

       ### 自定义Spring Boot Starter实现

       按照葫芦画瓢的思路，我们将创建一个猜数字游戏服务的自定义Starter。首先，定义项目结构，添加依赖配置，创建Service和自动配置类，设置条件注解以实现自动装配功能。接着，编写配置文件和自动装配类，完成自动装配的机制。

       在完成自定义Starter的构建后，我们将该Starter引入到游戏服务端的配置中，通过application.properties文件开启自动装配功能。至此，游戏服务端可以自动装配所需的组件，简化了代码的编写和维护。

       通过实际运行GameApplication，我们可以看到游戏服务端通过自动装配成功运行猜数字游戏，验证了自定义Starter的正确性。

       ### 总结

       本文详细介绍了如何通过自定义Spring Boot Starter来实现自动装配的功能，从代码层面深入理解了Spring Boot的自动装配机制。通过本次实践，我们不仅掌握了如何构建自定义Starter，还对Spring Boot的自动装配原理有了更直观的认识。接下来，我们将继续深入源码解析，探讨自动装配实现的细节，敬请期待！

数据库连接池之Hikari

       作为数据库连接池的佼佼者，HikariCP因其卓越的猪币源码性能而备受推崇，尤其在SpringBoot2.0以后成为了默认选用的连接池。它的配置参数如autoCommit、connectionTimeout等，如autoCommit默认为true，用于自动提交从池中获取的连接。connectionTimeout设定了最大等待时间，idleTimeout则控制连接在池中的最长闲置时间，两者共同确保了连接的有效管理。keepaliveTime确保连接的存活，而maxLifetime则设定连接的最长生命周期，建议用户设置以优化性能。minimumIdle用于维护连接池的最小空闲连接数，而maximumPoolSize则控制最大连接数，poolName则是用于标识池的唯一名称。

       HikariCP的高性能主要源于其技术优化。首先，它采用FastList替代ArrayList，提高get和remove操作的效率。其次，通过预先初始化避免了同步处理，提升初始化速度。动态字节码生成技术使得连接创建更为迅速。连接获取时，HikariCP在threadLocal中进行缓存，降低了线程间的并发冲突。同时，HikariCP设计目标在于减少锁竞争，确保在高并发环境中的稳定表现。关于更深入的解析，可以参考《非正经程序员：Spring Boot中使用Hikari，给我整不会了》和《数据库连接池之Hikari源码解析 - Lucky帅小武 - 博客园》等文章，ssc源码打包以及《Springboot 2.0默认连接池HikariCP详解（效率最高）》。

driver does not support get/ set network timeout for connections错误的原因是什么？

       Driver does not support get/set network timeout for connections错误的原因：pringboot 2.x默认的数据源变成了HikariPool了，弄了一个demo在使用数据源的时候系统报错 HikariPool-1 - Driver does not support get/set network timeout for connections. (null)。

       具体的解决办法：通过源码排查到连接验证有两种方式，一种是HikariPool自带的，具体逻辑没看，如果没适配对应的驱动就会报上面的错误；另一种是使用ConnectionTestQuery 这个属性来验证。那行代码大概就是：boolean isUseJdbc4Validation = getConnectionTestQuery == null;

       如果这个属性没有配置，则使用默认的，若配置了，则使用自行配置的。所以只需要配置一下测试脚本即可。

扩展资料：

       SpringBoot框架：

       SpringBoot框架中还有两个非常重要的策略：开箱即用和约定优于配置。开箱即用，Outofbox，是指在开发过程中，通过在MAVEN项目的pom文件中添加相关依赖包，然后使用对应注解来代替繁琐的XML配置文件以管理对象的生命周期。这个特点使得开发人员摆脱了复杂的配置工作以及依赖的管理工作，更加专注于业务逻辑。

       约定优于配置，Convention over configuration，是一种由SpringBoot本身来配置目标结构，由开发者在结构中添加信息的软件设计范式。这一特点虽降低了部分灵活性，增加了BUG定位的复杂性，但减少了开发人员需要做出决定的数量，同时减少了大量的XML配置，并且可以将代码编译、测试和打包等工作自动化。

       百度百科-Spring Boot

Hikari源码分析 - AntiDebug

       一、抱抱秀源码框架分析

       针对PASS的具体实现进行深入分析。该PASS旨在提升编译后程序的抵抗调试能力，其核心逻辑包括两个主要方面：

       链接预编译的反调试IR代码

       特定于平台的内联汇编注入

       针对Darwin操作系统上的AArch架构，若未找到ADBCallBack和InitADB函数，PASS会尝试直接注入内联汇编代码。该代码片段可能利用系统调用，如ptrace，来检测是否处于调试环境。

       此外，配置允许用户指定预编译反调试IR文件的路径和函数混淆概率。

       具体实现包括：

       检查预编译IR路径，构建默认路径并链接预编译的IR文件。

       修改ADBCallBack和InitADB函数属性，确保它们在编译和链接阶段表现出反调试行为。

       初始化标志和目标三元组信息，准备为每个模块提供初始化和链接预编译IR的过程。

       模块处理和函数处理涉及应用概率值来决定是否对模块和函数应用反调试混淆。

       预编译的反调试IR文件包含了一系列用于反调试的函数和结构，如检测调试器的代码、修改执行路径以规避调试跟踪、以及插桩代码以检测异常行为。

       通过LLVM工具链中的llvm-dis工具，可以将.bc文件转换为可读的LLVM IR文件。该文件结构包含多个结构体定义、全局声明、函数实现和属性。

       函数ADBCallBack简单地终止程序并执行无法到达的指令。函数InitADB执行系统调用和检查来检测调试状态，可能涉及进程信息查询、动态库加载、系统调用、内存分配、异常端口检查等操作。

       系统调用声明确保了程序能调用各种底层函数进行操作，如sysctl、dlopen、dlsym、task_get_exception_ports、isatty、ioctl等。

       总结，通过在编译器优化阶段插入反调试逻辑，相较于源代码实现，基于LLVM Pass的AntiDebug方法提供了更好的隐蔽性、可移植性、灵活性、维护性和混淆程度。然而，这种方法需要对LLVM框架有深入理解，可能增加构建和调试复杂度。

wvp-GB-pro的安装与调试

       本文将深入探讨WVP-GB-pro的安装与调试过程，特别关注其与ZLMediaKit的集成。首先，我们比较了几种GB服务模型，最后选定gosip+ZLMediaKit、Monibuca插件式和WVP-GB-pro+ZLMediaKit，本章节将重点讲解后者。

       要开始安装，你可以从GitHub或Gitee下载最新版本的WVP-PRO软件，它支持多种主流监控品牌设备，如海康威视和大华。

       安装步骤如下：

基础环境准备：首先，安装Docker并在其内构建Redis、MySQL和ZLMediaKit环境。Redis用于存储和缓存，MySQL用于数据库，ZLMediaKit负责媒体处理。

Docker安装Redis：检查版本、下载镜像，设置映射端口，确保正常运行。

MySQL Docker安装：参考相关技术文章，配置数据库连接参数。

ZLMediaKit Docker安装：利用官方提供的安装命令，快速集成到项目中。

WVP-GB-pro编译：从源代码仓库获取，配置静态网页、打包jar，并调整必要的配置参数。

配置要点：例如，上传文件限制(max-file-size: MB, max-request-size: MB)、网络连接(REDIS: host、port等)、数据库连接(JDBC类型、驱动等)、数据映射(mybatis)、HTTP和HTTPS设置，以及SIP服务器配置等。

       以下是一些关键配置项的示例：

上传文件限制:max-file-size: MB, max-request-size: MB

REDIS连接:host: ..., port: , DB: 6, password: , timeout:

JDBC配置:HikariDataSource类型，驱动com.mysql.cj.jdbc.Driver, ...

mybatis映射:map-underscore-to-camel-case: true

HTTP服务器设置:server: port:

HTTPS配置:enabled: false, key-store: xxx.jks, key-store-password: password

SIP服务器配置:IP: ..1., port:

       在实际操作中，务必根据具体需求调整这些配置。务必注意，由于篇幅限制，部分详细教程链接和编译过程中的具体步骤已省略，建议查阅完整的文档或教程以确保每个环节的正确执行。

       最后，对于媒体参数获取和测试，推荐使用Apifox查询接口index/api/getServerConfig，以及强大的测试工具GB_ServerPlatform，通过其Client目录下的工具进行平台信息查看和实时视频播放测试。

       通过以上详细的安装步骤和配置指南，相信您已经对WVP-GB-pro的安装与调试有了一定的理解。接下来，可以根据这些信息逐步实施，确保监控系统的顺利集成和运行。

弹性数据库连接池探活策略调研 (二)——Druid | 京东云技术团队

       在上篇文章中，我们探讨了 HikariCP 连接池的探活策略，现在我们将转向另一个流行的数据库连接池——Druid。京东云技术团队将为您揭示如何在使用Druid时实现最佳的弹性数据库连接池探活策略，以及其不同版本间的参数调整与实现逻辑。

       Druid的探活机制复杂且版本间差异明显，配置参数众多。核心的探活逻辑主要集中在两个源码函数中。要确保探活策略生效，需理解以下几个关键参数：testOnBorrow、testWhileIdle和timeBetweenEvictionRunsMillis。在高并发场景下，推荐配置testWhileIdle以减少性能消耗。

       Druid的getConnectionDirect函数在取连接时会进行探活检测，如果testOnBorrow为true，每次都会检查连接有效性。当testOnBorrow为false且testWhileIdle为true时，会根据timeBetweenEvictionRunsMillis来判断连接是否失效，若超过设定时间，则进行探活。在版本1.1.及以上，保持连接功能（keepAlive）在minEvictableIdleTimeMillis设置小于分钟时，有助于高效探活并防止网关连接关闭。

       在低版本中，如1.0.9，探活主要依赖于testOnBorrow或testWhileIdle，不支持keepAlive。而在1.1.和1.1.9版本中，shrink方法的逻辑有所调整，引入了keepAliveBetweenTimeMillis参数，增加了对keepAlive的控制。1.1.版本则进一步优化了探活过程，不仅关闭无效连接，还会补充连接以维持最小连接数。

       总结来说，Druid的探活策略在不同版本中需灵活配置，建议在高并发场景下使用1.1.或更高版本，配置testWhileIdle以提高性能，同时根据需求选择是否启用testOnBorrow或使用keepAlive来保证连接的可用性。对于使用Druid连接池的线上应用，推荐依据实际需求选择合适的版本和参数设置。

       以上内容由京东零售王雷鑫提供，出自京东云开发者社区，转载请注明原作者和来源。

源码详解系列(八)--全面讲解HikariCP的使用和源码

       源码详解系列(八)：HikariCP深度剖析

       HikariCP是一个高效数据库连接池，它的核心在于通过“池”复用连接，减少创建和关闭连接的开销。本文将全面介绍HikariCP的使用方法和源码细节。

       使用场景与内容

       本文将涉及HikariCP的以下内容：

       如何获取连接对象并进行基本操作

       项目环境设置，包括JDK、Maven版本和依赖库

       如何配置HikariCP，包括依赖引入和配置文件编写

       初始化连接池，以及通过JMX进行管理

       源码分析，重点讲解ConcurrentBag和HikariPool类，以及其创新的“标记模型”

       HikariDataSource的两个HikariPool的用意和加载配置

       核心原理

       HikariCP的性能优势主要源于其“标记模型”，通过减少锁的使用，提高并发性能。它使用CopyOnWriteArrayList来保证读操作的效率，结合CAS机制实现无锁的借出和归还操作。

       源码亮点

       源码简洁且易读，特别是ConcurrentBag类，它是HikariCP的核心组件。类结构与DBCP2类似，包含一个通用的资源池，可以应用于其他需要池化管理的场景。

       总结

       通过本文，读者可以深入了解HikariCP的工作原理，掌握其配置和使用技巧，以及源码实现。希望本文对数据库连接池有深入理解的开发者有所帮助。

       

参考资料：

HikariCP官方GitHub地址