slf4j与jul、log4j1、log4j2、logback的集成原理
转自:http://my.oschina.net/pingpangkuangmo/blog/408382
1 系列目录
- jdk-logging、log4j、logback日志介绍及原理
- commons-logging与jdk-logging、log4j1、log4j2、logback的集成原理
- slf4j与jdk-logging、log4j1、log4j2、logback的集成原理
- slf4j、jcl、jul、log4j1、log4j2、logback大总结
2 slf4j
先从一个简单的使用案例来说明
2.1 简单的使用案例
private static Logger logger=LoggerFactory.getLogger(Log4jSlf4JTest.class);
public static void main(String[] args){
if(logger.isDebugEnabled()){
logger.debug("slf4j-log4j debug message");
}
if(logger.isInfoEnabled()){
logger.debug("slf4j-log4j info message");
}
if(logger.isTraceEnabled()){
logger.debug("slf4j-log4j trace message");
}
}
上述Logger接口、LoggerFactory类都是slf4j自己定义的。
2.2 使用原理
LoggerFactory.getLogger(Log4jSlf4JTest.class)的源码如下:
public static Logger getLogger(String name) {
ILoggerFactory iLoggerFactory = getILoggerFactory();
return iLoggerFactory.getLogger(name);
}
上述获取Log的过程大致分成2个阶段
- 获取ILoggerFactory的过程 (从字面上理解就是生产Logger的工厂)
- 根据ILoggerFactory获取Logger的过程
下面来详细说明:
-
1 获取ILoggerFactory的过程
又可以分成3个过程:
-
1.1 从类路径中寻找org/slf4j/impl/StaticLoggerBinder.class类
ClassLoader.getSystemResources("org/slf4j/impl/StaticLoggerBinder.class")
如果找到多个,则输出 Class path contains multiple SLF4J bindings,表示有多个日志实现与slf4j进行了绑定
下面看下当出现多个StaticLoggerBinder的时候的输出日志(简化了一些内容):
SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [slf4j-log4j12-1.7.12.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [logback-classic-1.1.3.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [slf4j-jdk14-1.7.12.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
-
1.2 “随机选取"一个StaticLoggerBinder.class来创建一个单例
StaticLoggerBinder.getSingleton()
这里的"随机选取"可以见官方文档说明:
SLF4J API is designed to bind with one and only one underlying logging framework at a time. If more than one binding is present on the class path, SLF4J will emit a warning, listing the location of those bindings
The warning emitted by SLF4J is just that, a warning. Even when multiple bindings are present,SLF4J will pick one logging framework/implementation and bind with it. The way SLF4J picks a binding is determined by the JVM and for all practical purposes should be considered random
-
1.3 根据上述创建的StaticLoggerBinder单例,返回一个ILoggerFactory实例
StaticLoggerBinder.getSingleton().getLoggerFactory()
所以slf4j与其他实际的日志框架的集成jar包中,都会含有这样的一个org/slf4j/impl/StaticLoggerBinder.class类文件,并且提供一个ILoggerFactory的实现
-
-
2 根据ILoggerFactory获取Logger的过程
这就要看具体的ILoggerFactory类型了,下面的集成来详细说明
3 slf4j与jdk-logging集成
3.1 需要的jar包
- slf4j-api
- slf4j-jdk14
对应的maven依赖为:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.12</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-jdk14</artifactId>
<version>1.7.12</version>
</dependency>
3.2 使用案例
private static final Logger logger=LoggerFactory.getLogger(JulSlf4jTest.class);
public static void main(String[] args){
if(logger.isDebugEnabled()){
logger.debug("jul debug message");
}
if(logger.isInfoEnabled()){
logger.info("jul info message");
}
if(logger.isWarnEnabled()){
logger.warn("jul warn message");
}
}
上述的Logger、LoggerFactory都是slf4j自己的API中的内容,没有jdk自带的logging的踪影,然后打出来的日志却是通过jdk自带的logging来输出的,如下:
四月 28, 2015 7:33:20 下午 com.demo.log4j.JulSlf4jTest main
信息: jul info message
四月 28, 2015 7:33:20 下午 com.demo.log4j.JulSlf4jTest main
警告: jul warn message
3.3 使用案例原理分析
先看下slf4j-jdk14 jar包中的内容:
从中可以看到:
- 的确是有org/slf4j/impl/StaticLoggerBinder.class类
- 该StaticLoggerBinder返回的ILoggerFactory类型将会是JDK14LoggerFactory
- JDK14LoggerAdapter就是实现了slf4j定义的Logger接口
下面梳理下整个流程:
-
1 获取ILoggerFactory的过程
由于类路径下有org/slf4j/impl/StaticLoggerBinder.class,所以会选择slf4j-jdk14中的StaticLoggerBinder来创建单例对象并返回ILoggerFactory,来看下StaticLoggerBinder中的ILoggerFactory是什么类型:
private StaticLoggerBinder() { loggerFactory = new org.slf4j.impl.JDK14LoggerFactory(); }
所以返回了JDK14LoggerFactory的实例
-
2 根据ILoggerFactory获取Logger的过程
来看下JDK14LoggerFactory是如何返回一个slf4j定义的Logger接口的实例的,源码如下:
java.util.logging.Logger julLogger = java.util.logging.Logger.getLogger(name); Logger newInstance = new JDK14LoggerAdapter(julLogger);
可以看到,就是使用jdk自带的logging的原生方式来先创建一个jdk自己的java.util.logging.Logger实例,参见jdk-logging的原生写法
然后利用JDK14LoggerAdapter将上述的java.util.logging.Logger包装成slf4j定义的Logger实例
所以我们使用slf4j来进行编程,最终会委托给jdk自带的java.util.logging.Logger去执行。
4 slf4j与log4j1集成
4.1 需要的jar包
- slf4j-api
- slf4j-log4j12
- log4j
maven依赖分别为:
<!-- slf4j -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.12</version>
</dependency>
<!-- slf4j-log4j -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.12</version>
</dependency>
<!-- log4j -->
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
</dependency>
4.2 使用案例
-
第一步:编写log4j.properties配置文件,放到类路径下
log4j.rootLogger = debug, console log4j.appender.console = org.apache.log4j.ConsoleAppender log4j.appender.console.layout = org.apache.log4j.PatternLayout log4j.appender.console.layout.ConversionPattern = %-d{yyyy-MM-dd HH:mm:ss} %m%n
配置文件的详细内容不是本博客关注的重点,不再说明,自行搜索
-
第二步:代码中如下使用
private static Logger logger=LoggerFactory.getLogger(Log4jSlf4JTest.class); public static void main(String[] args){ if(logger.isDebugEnabled()){ logger.debug("slf4j-log4j debug message"); } if(logger.isInfoEnabled()){ logger.info("slf4j-log4j info message"); } if(logger.isTraceEnabled()){ logger.trace("slf4j-log4j trace message"); } }
-
补充说明:
-
1 配置文件同样可以随意放置,如log4j1原生方式加载配置文件的方式log4j1原生开发
-
2 注意两者方式的不同:
slf4j: Logger logger=LoggerFactory.getLogger(Log4jSlf4JTest.class); log4j: Logger logger=Logger.getLogger(Log4jTest.class);
slf4j的Logger是slf4j定义的接口,而log4j的Logger是类。LoggerFactory是slf4j自己的类
-
4.3 使用案例原理分析
先来看下slf4j-log4j12包中的内容:
- 的确是有org/slf4j/impl/StaticLoggerBinder.class类
- 该StaticLoggerBinder返回的ILoggerFactory类型将会是Log4jLoggerFactory
- Log4jLoggerAdapter就是实现了slf4j定义的Logger接口
来看下具体过程:
-
1 获取对应的ILoggerFactory
从上面的slf4j的原理中我们知道:ILoggerFactory是由StaticLoggerBinder来创建出来的,所以可以简单分成2个过程:
-
1.1 第一个过程:slf4j寻找绑定类StaticLoggerBinder
使用ClassLoader来加载 “org/slf4j/impl/StaticLoggerBinder.class"这样的类的url,然后就找到了slf4j-log4j12包中的StaticLoggerBinder
-
1.2 第二个过程:创建出StaticLoggerBinder实例,并创建出ILoggerFactory
源码如下:
StaticLoggerBinder.getSingleton().getLoggerFactory()
以slf4j-log4j12中的StaticLoggerBinder为例,创建出的ILoggerFactory为Log4jLoggerFactory
-
-
2 根据ILoggerFactory获取Logger的过程
来看下Log4jLoggerFactory是如何返回一个slf4j定义的Logger接口的实例的,源码如下:
org.apache.log4j.Logger log4jLogger; if (name.equalsIgnoreCase(Logger.ROOT_LOGGER_NAME)) log4jLogger = LogManager.getRootLogger(); else log4jLogger = LogManager.getLogger(name); Logger newInstance = new Log4jLoggerAdapter(log4jLogger);
-
2.1 我们可以看到是通过log4j1的原生方式,即使用log4j1的LogManager来获取,引发log4j1的加载配置文件,然后初始化,最后返回一个org.apache.log4j.Logger log4jLogger,参见log4j1原生的写法
-
2.2 将上述的org.apache.log4j.Logger log4jLogger封装成Log4jLoggerAdapter,而Log4jLoggerAdapter是实现了slf4j的接口,所以我们使用的slf4j的Logger接口实例(这里即Log4jLoggerAdapter)都会委托给内部的org.apache.log4j.Logger实例
-
5 slf4j与log4j2集成
5.1 需要的jar包
- slf4j-api
- log4j-api
- log4j-core
- log4j-slf4j-impl (用于log4j2与slf4j集成)
对应的maven依赖分别是:
<!-- slf4j -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.12</version>
</dependency>
<!-- log4j2 -->
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.2</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.2</version>
</dependency>
<!-- log4j-slf4j-impl -->
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-slf4j-impl</artifactId>
<version>2.2</version>
</dependency>
5.2 使用案例
-
第一步:编写log4j2的配置文件log4j2.xml,简单如下:、
<?xml version="1.0" encoding="UTF-8"?> <Configuration status="WARN"> <Appenders> <Console name="Console" target="SYSTEM_OUT"> <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/> </Console> </Appenders> <Loggers> <Root level="debug"> <AppenderRef ref="Console"/> </Root> </Loggers> </Configuration>
-
第二步:使用方式
private static Logger logger=LoggerFactory.getLogger(Log4j2Slf4jTest.class); public static void main(String[] args){ if(logger.isTraceEnabled()){ logger.trace("slf4j-log4j2 trace message"); } if(logger.isDebugEnabled()){ logger.debug("slf4j-log4j2 debug message"); } if(logger.isInfoEnabled()){ logger.info("slf4j-log4j2 info message"); } }
5.3 使用案例原理分析
先来看下log4j-slf4j-impl包中的内容:
- 的确是有org/slf4j/impl/StaticLoggerBinder.class类
- 该StaticLoggerBinder返回的ILoggerFactory类型将会是Log4jLoggerFactory(这里的Log4jLoggerFactory与上述log4j1集成时的Log4jLoggerFactory是不一样的)
- Log4jLogger就是实现了slf4j定义的Logger接口
来看下具体过程:
-
1 获取对应的ILoggerFactory
-
1.1 第一个过程:slf4j寻找绑定类StaticLoggerBinder
使用ClassLoader来加载 “org/slf4j/impl/StaticLoggerBinder.class"这样的类的url,然后就找到了log4j-slf4j-impl包中的StaticLoggerBinder
-
1.2 第二个过程:创建出StaticLoggerBinder实例,并创建出ILoggerFactory
log4j-slf4j-impl包中的StaticLoggerBinder返回的ILoggerFactory是Log4jLoggerFactory
-
-
2 根据ILoggerFactory获取Logger的过程
来看下Log4jLoggerFactory是如何返回一个slf4j定义的Logger接口的实例的,源码如下:
@Override protected Logger newLogger(final String name, final LoggerContext context) { final String key = Logger.ROOT_LOGGER_NAME.equals(name) ? LogManager.ROOT_LOGGER_NAME : name; return new Log4jLogger(context.getLogger(key), name); } @Override protected LoggerContext getContext() { final Class<?> anchor = ReflectionUtil.getCallerClass(FQCN, PACKAGE); return anchor == null ? LogManager.getContext() : getContext(ReflectionUtil.getCallerClass(anchor)); }
-
2.1 我们可以看到是通过log4j2的原生方式,即使用log4j2的LoggerContext来获取,返回一个org.apache.logging.log4j.core.Logger即log4j2定义的Logger接口实例,参见log4j2原生的写法
-
2.2 将上述的org.apache.logging.log4j.core.Logger封装成Log4jLogger,而Log4jLogger是实现了slf4j的Logger接口的,所以我们使用的slf4j的Logger接口实例(这里即Log4jLogger)都会委托给内部的log4j2定义的Logger实例。
上述获取LoggerContext的过程也是log4j2的原生方式:
LogManager.getContext()
该操作会去加载log4j2的配置文件,引发log4j2的初始化
-
6 slf4j与logback集成
6.1 需要的jar包
- slf4j-api
- logback-core
- logback-classic(已含有对slf4j的集成包)
对应的maven依赖为:
<!-- slf4j-api -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.12</version>
</dependency>
<!-- logback -->
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<version>1.1.3</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.1.3</version>
</dependency>
6.2 使用案例
-
第一步:编写logback的配置文件logback.xml,简单如下:
<?xml version="1.0" encoding="UTF-8"?> <configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern> </encoder> </appender> <root level="DEBUG"> <appender-ref ref="STDOUT" /> </root> </configuration>
-
第二步:使用方式
private static final Logger logger=LoggerFactory.getLogger(LogbackTest.class); public static void main(String[] args){ if(logger.isDebugEnabled()){ logger.debug("slf4j-logback debug message"); } if(logger.isInfoEnabled()){ logger.info("slf4j-logback info message"); } if(logger.isTraceEnabled()){ logger.trace("slf4j-logback trace message"); } }
6.3 使用案例原理分析
先来看下logback-classic包中与slf4j集成的内容:
-
的确是有org/slf4j/impl/StaticLoggerBinder.class类
-
该StaticLoggerBinder返回的ILoggerFactory类型将会是LoggerContext(logback的对象)
-
logback自己定义的ch.qos.logback.classic.Logger类就是实现了slf4j定义的Logger接口
-
1 获取对应的ILoggerFactory
-
1.1 第一个过程:slf4j寻找绑定类StaticLoggerBinder
使用ClassLoader来加载 “org/slf4j/impl/StaticLoggerBinder.class"这样的类的url,然后就找到了logback-classic包中的StaticLoggerBinder
-
1.2 第二个过程:创建出StaticLoggerBinder实例,并创建出ILoggerFactory
logback-classic包中的StaticLoggerBinder返回的ILoggerFactory是LoggerContext(logback的对象)
创建出单例后,同时会引发logback的初始化,这时候logback就要去寻找一系列的配置文件,尝试加载并解析。
-
-
2 根据ILoggerFactory获取Logger的过程
来看下LoggerContext(logback的对象)是如何返回一个slf4j定义的Logger接口的实例的:
该LoggerContext(logback的对象)返回的ch.qos.logback.classic.Logger(logback的原生Logger对象)就是slf4j的Logger实现类。
7 未完待续
本篇文章讲解了slf4j与jdk-logging、log4j1、log4j2、logback的集成原理,下一篇也是最后一篇来总结下
- 各种jar包的总结
- commons-logging、slf4j与其他日志框架的集成总结
- 实现已有的日志框架无缝切换到别的日志框架(如已使用log4j进行日志记录的代码最终转到logback来输出)
- jar包冲突说明
相关推荐
NULL 博文链接:https://tristan-s.iteye.com/blog/1966020
4. SLF4J与其他日志框架的关系: - **适配器**:SLF4J提供了适配器模块,如`slf4j-log4j12`,用于将SLF4J接口绑定到Log4j实现。 - **桥接器**:对于已使用特定日志系统的代码,SLF4J还提供了桥接器,如`jul-to-slf...
视频详细讲解,需要的小伙伴自行网盘下载,链接见附件,... logback-access使用章节七:Log4j21. 快速入门2. 配置文件3. 异步日志4. 性能介绍章节八:SpringBoot使用日志1. springBoot日志设计2. springBoot日志使用
- 如果需要与现有使用Log4j的项目集成,则可能需要考虑Log4j2。 #### 3. 如何选择合适的日志框架 - **评估项目需求**: - 考虑项目的规模、日志需求的复杂度以及团队的技术背景。 - 新项目建议采用SLF4J + ...
在智慧园区建设的浪潮中,一个集高效、安全、便捷于一体的综合解决方案正逐步成为现代园区管理的标配。这一方案旨在解决传统园区面临的智能化水平低、信息孤岛、管理手段落后等痛点,通过信息化平台与智能硬件的深度融合,为园区带来前所未有的变革。 首先,智慧园区综合解决方案以提升园区整体智能化水平为核心,打破了信息孤岛现象。通过构建统一的智能运营中心(IOC),采用1+N模式,即一个智能运营中心集成多个应用系统,实现了园区内各系统的互联互通与数据共享。IOC运营中心如同园区的“智慧大脑”,利用大数据可视化技术,将园区安防、机电设备运行、车辆通行、人员流动、能源能耗等关键信息实时呈现在拼接巨屏上,管理者可直观掌握园区运行状态,实现科学决策。这种“万物互联”的能力不仅消除了系统间的壁垒,还大幅提升了管理效率,让园区管理更加精细化、智能化。 更令人兴奋的是,该方案融入了诸多前沿科技,让智慧园区充满了未来感。例如,利用AI视频分析技术,智慧园区实现了对人脸、车辆、行为的智能识别与追踪,不仅极大提升了安防水平,还能为园区提供精准的人流分析、车辆管理等增值服务。同时,无人机巡查、巡逻机器人等智能设备的加入,让园区安全无死角,管理更轻松。特别是巡逻机器人,不仅能进行360度地面全天候巡检,还能自主绕障、充电,甚至具备火灾预警、空气质量检测等环境感知能力,成为了园区管理的得力助手。此外,通过构建高精度数字孪生系统,将园区现实场景与数字世界完美融合,管理者可借助VR/AR技术进行远程巡检、设备维护等操作,仿佛置身于一个虚拟与现实交织的智慧世界。 最值得关注的是,智慧园区综合解决方案还带来了显著的经济与社会效益。通过优化园区管理流程,实现降本增效。例如,智能库存管理、及时响应采购需求等举措,大幅减少了库存积压与浪费;而设备自动化与远程监控则降低了维修与人力成本。同时,借助大数据分析技术,园区可精准把握产业趋势,优化招商策略,提高入驻企业满意度与营收水平。此外,智慧园区的低碳节能设计,通过能源分析与精细化管理,实现了能耗的显著降低,为园区可持续发展奠定了坚实基础。总之,这一综合解决方案不仅让园区管理变得更加智慧、高效,更为入驻企业与员工带来了更加舒适、便捷的工作与生活环境,是未来园区建设的必然趋势。
labelme标注的json转mask掩码图,用于分割数据集 批量转化,生成cityscapes格式的数据集
(参考GUI)MATLAB GUI漂浮物垃圾分类检测.zip
人脸识别项目源码实战
人脸识别项目实战
本仿真模型基于MATLAB/Simulink(版本MATLAB 2016Rb)软件。建议采用matlab2016 Rb及以上版本打开。(若需要其他版本可联系代为转换) CSDN详情地址:https://blog.csdn.net/qq_50594161/article/details/146242453sharetype=blogdetail&sharerId=146242453&sharerefer=PC&sharesource=qq_50594161&spm=1011.2480.3001.8118
实战练习分词、创建词表、文本处理
在智慧园区建设的浪潮中,一个集高效、安全、便捷于一体的综合解决方案正逐步成为现代园区管理的标配。这一方案旨在解决传统园区面临的智能化水平低、信息孤岛、管理手段落后等痛点,通过信息化平台与智能硬件的深度融合,为园区带来前所未有的变革。 首先,智慧园区综合解决方案以提升园区整体智能化水平为核心,打破了信息孤岛现象。通过构建统一的智能运营中心(IOC),采用1+N模式,即一个智能运营中心集成多个应用系统,实现了园区内各系统的互联互通与数据共享。IOC运营中心如同园区的“智慧大脑”,利用大数据可视化技术,将园区安防、机电设备运行、车辆通行、人员流动、能源能耗等关键信息实时呈现在拼接巨屏上,管理者可直观掌握园区运行状态,实现科学决策。这种“万物互联”的能力不仅消除了系统间的壁垒,还大幅提升了管理效率,让园区管理更加精细化、智能化。 更令人兴奋的是,该方案融入了诸多前沿科技,让智慧园区充满了未来感。例如,利用AI视频分析技术,智慧园区实现了对人脸、车辆、行为的智能识别与追踪,不仅极大提升了安防水平,还能为园区提供精准的人流分析、车辆管理等增值服务。同时,无人机巡查、巡逻机器人等智能设备的加入,让园区安全无死角,管理更轻松。特别是巡逻机器人,不仅能进行360度地面全天候巡检,还能自主绕障、充电,甚至具备火灾预警、空气质量检测等环境感知能力,成为了园区管理的得力助手。此外,通过构建高精度数字孪生系统,将园区现实场景与数字世界完美融合,管理者可借助VR/AR技术进行远程巡检、设备维护等操作,仿佛置身于一个虚拟与现实交织的智慧世界。 最值得关注的是,智慧园区综合解决方案还带来了显著的经济与社会效益。通过优化园区管理流程,实现降本增效。例如,智能库存管理、及时响应采购需求等举措,大幅减少了库存积压与浪费;而设备自动化与远程监控则降低了维修与人力成本。同时,借助大数据分析技术,园区可精准把握产业趋势,优化招商策略,提高入驻企业满意度与营收水平。此外,智慧园区的低碳节能设计,通过能源分析与精细化管理,实现了能耗的显著降低,为园区可持续发展奠定了坚实基础。总之,这一综合解决方案不仅让园区管理变得更加智慧、高效,更为入驻企业与员工带来了更加舒适、便捷的工作与生活环境,是未来园区建设的必然趋势。
人脸识别项目源码实战
学生信息管理系统是一个基于Java Web技术的综合性管理平台。通过此系统,可以实现对学生、教师、选课信息等的动态管理, 提升学校管理效率。系统采用分层架构设计,前端使用HTML、CSS,JavaScript和jQuery,后端基于Servlet,JSP和Spring框架,数据库采用MySQL。主要有四个大功能,学生管理( 增加学生信息、删除学生信息、修改学生信息、查询学生信息)、教师管理(增加教师信息、删除教师信息、修改教师信息、查询教师信息)、选课信息管理(添加选课、查询选课情况、删除选课记录)、系统管理( 登录与注册功能、 用户角色管理(老师,学生,管理员)、系统日志查看)。 技术架构 1.前端技术 HTML,CSS:静态页面布局与样式 JavaScript,jQuery:动态交互、DOM操作和AJAX请求 2.后端技术 Servlet:控制层,处理用户请求 JSP:页面动态生成 Spring:依赖注入,业务逻辑分离 3.数据库 MySQL:存储学生、教师,课程等数据 JDBC:数据库连接与操作
本课程是 PHP 进阶系列之 Swoole 入门精讲,系统讲解 Swoole 在 PHP 高性能开发中的应用,涵盖 协程、异步编程、WebSocket、TCP/UDP 通信、任务投递、定时器等核心功能。通过理论解析和实战案例相结合,帮助开发者掌握 Swoole 的基本使用方法及其在高并发场景下的应用。 适用人群: 适合 有一定 PHP 基础的开发者、希望提升后端性能优化能力的工程师,以及 对高并发、异步编程感兴趣的学习者。 能学到什么: 掌握 Swoole 基础——理解 Swoole 的核心概念,如协程、异步编程、事件驱动等。 高并发处理——学习如何使用 Swoole 构建高并发的 Web 服务器、TCP/UDP 服务器。 实战项目经验——通过案例实践,掌握 Swoole 在 WebSocket、消息队列、微服务等场景的应用。 阅读建议: 建议先掌握 PHP 基础,了解 HTTP 服务器和并发处理相关概念。学习过程中,结合 官方文档和实际项目 进行实践,加深理解,逐步提升 Swoole 开发能力。
人脸识别项目实战
人脸识别项目实战
功能简介:本工具可实现批量对照片文件的人脸识别,并按指定分辨率进行转换保存。 可为人脸识别采集系统提供很好的辅助工具。 软件基本于OPENVC开发,识别精确,转换高效。 人脸识别工具 +人脸采集处理
内容概要:本文探讨了利用肌长变化反馈控制(FCM-ML)和演员-评论家强化学习(ACRL-NGN)来有效实现人体上肢和下肢无意识姿态稳定的算法方法。通过构建一个包含949条肌肉和22个关节的全身计算模型,在不同初始姿势的情况下进行模拟试验,验证了这些方法的有效性和鲁棒性,结果显示FCM-ML方法比其他传统方法更适用于此类任务。研究指出人类及其他脊椎动物在无意识状态下,通过抗拮抗性的肌肉长度变化反馈机制来维持舒适状态下的自然身体姿势(NBP)。此外,研究还表明这种控制策略有助于机器人设计、运动员训练以及康复患者的治疗。 适用人群:生物力学、机器人学以及神经科学领域的研究人员、工程师,以及关注人体姿态控制及其应用的学者和技术人员。 使用场景及目标:①解释人和非人的脊椎动物如何在无意识情况下维持最佳姿势,特别是处于重力环境中的自然身体姿势(NBP)。②为机器人肌肉控制提供理论支持和发展方向,特别是在模拟多肌肉协调控制方面。③指导运动训练及病患恢复计划的设计与优化。 其他说明:研究发现ACRL-NGN结合FCM-ML不仅能够迅速有效地实现期望的姿态稳定性,而且不需要对肌肉分类,这使其在复