2024年11月

概述

SpringMVC 中的 MVC 即模型-视图-控制器,该框架围绕一个 DispatcherServlet 改计而成,DispatcherServlet 会把请求分发给各个处理器,并支持可配置的处理器映射和视图渲染等功能

SpringMVC 的工作流程如下所示:

  1. 客户端发起 HTTP 请求:客户端将请求提交到 DispatcherServlet
  2. 寻找处理器:DispatcherServlet 控制器查询一个或多个 HandlerMapping,找到处理该请求的 Controller
  3. 调用处理器:DispatcherServlet 将请求提交到 Controller
  4. 调用业务处理逻辑并返回结果:Controller 在调用业务处理逻辑后,返回 ModelAndView
  5. 处理视图映射并返回模型:DispatcherServlet 查询一个或多个 ViewResolver 视图解析器,找到 ModelAndView 指定的视图
  6. HTTP 响应:视图负责将结果在客户端浏览器上谊染和展示


DispatcherServlet

在 Java 中可以使用 Servlet 来处理请求,客户端每次发出请求,Servlet 会调用 service 方法来处理,SpringMVC 通过创建 DispatchServlet 来统一接收请求并分发处理

1. 创建 DispatcherServlet

在 Tomcat 中创建 DispatcherServlet 的方式有两种:

第一种方式是通过 web.xml,Tomcat 会在启动时加载根路径下 /WEB-INF/web.xml 配置文件,根据其中的配置加载 Servlet,Listener,Filter 等,下面是 SpringMVC 的常见配置:

<servlet>
    <servlet-name>dispatcher</servlet>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <!--DispatchServlet 持有的 WebApplicationContext-->
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/applicationContext.xml</param-value>
        <!-- 1:tomcat 启动时创建 DispatcherServlet,0:tomcat 启动时不创建 DispatcherServlet,接收到请求才创建 -->
        <load-on-startup>1</load-on-startup>
    </init-param>
</servlet>

<servlet-mapping>
    <servlet-name>dispatch</servlet-name>
    <servlet-pattern>/*</servlet-pattern>
</servlet-mapping>

第二种方式是通过 WebApplicationInitializer,简单来说就是 Tomcat 会探测并加载 ServletContainerInitalizer 的实现类,并调用他的 onStartup 方法,而 SpringMVC 提供了对应的实现类 SpringServletContainerInitializer。而 SpringServletContainerInitializer 又会探测并加载 ClassPath 下 WebApplicationContextInitializer 的实现类,调用它的 onStartUp 方法

因此我们可以继承 WebApplicationContextInitializer 实现 onStartUp 方法,在其中以代码的方式配置 DispatchServlet

public class MyWebAppInitializer implements WebApplicationInitializer {
 
    @Override
    public void onStartup(ServletContext container) {

        // 创建 dispatcher 持有的上下文容器
        AnnotationConfigWebApplicationContext dispatcherContext = new AnnotationConfigWebApplicationContext();
        dispatcherContext.register(DispatcherConfig.class);

        // 注册、配置 dispatcher servlet
        ServletRegistration.Dynamic dispatcher = container.addServlet("dispatcher", new DispatcherServlet(dispatcherContext));
        dispatcher.setLoadOnStartup(1);
        dispatcher.addMapping("/*");
    }
}

在创建 DispatcherServlet 时,其内部会创建一个 Spring 容器 WebApplicationContext,目的是通过 Bean 的方式管理 Web 应用中的对象

2. DispatcherServlet 初始化

DispatcherServlet 是 Servlet 的实现类,Servlet的生命周期分为三个阶段:初始化、运行和销毁。初始化阶段会调用 init() 方法,DispatcherServlet 经过一系列封装,最终会调用 initStrategies 方法进行初始化,在这里我们重点关注 initHandlerMappings 和 initHandlerAdapters

protected void initStrategies(ApplicationContext context) {
    initMultipartResolver(context);
    initLocaleResolver(context);
    initThemeResolver(context);
    initHandlerMappings(context);
    initHandlerAdapters(context);
    initHandlerExceptionResolvers(context);
    initRequestToViewNameTranslator(context);
    initViewResolvers(context);
    initFlashMapManager(context);
}

initHandlerMappings 方法负责加载 HandlerMappings 也就是处理器映射器,如果程序员没有配置,那么 SpringMVC 也有默认提供的 HandlerMapping。每个 HandlerMapping 会以 Bean 的形式保持在容器,并执行各自的初始化方法。

默认的 HandlerMapping 有以下两种:

  • RequestMappingHandlerMapping:根据请求 URL 映射到对应 @RequestMapping 方法
  • BeanNameUrlHandlerMapping:根据请求 URL 映射到对应的 Bean 的名称(如该 Bean 的名称为 /test),这个 Bean 会提供一个处理请求逻辑的方法

RequestMappingHandlerMapping 在初始化的过程中会从处理器 bean(即被 @Controller 注解)中找出所有的处理方法(即被 @RequestMapping 注解),把处理方法的 @RequestMapping 注解解析成 RequestMappingInfo 对象,再把处理方法对象包装成 HandlerMethod 对象。然后把 RequestMappingInfo 和 HandlerMethod 对象以 map 的形式缓存起来,key 为 RequestMappingInfo,value 为 HandlerMethod,日后将请求映射到处理器时会使用到

BeanNameUrlHandlerMapping 在初始化的过程中会扫描 Spring 容器中所有的 bean,获取每个 bean 的名称以及对应的 Bean 保持起来。将每个 bean 的名称与请求的 URL 路径进行匹配,如果 bean 的名称与 URL 路径匹配(忽略大小写),那么就以匹配的 Bean 作为处理该请求的处理器。匹配 Bean 的实现如下:

@Componet("/welcome*")
public class WelcomeController implements Controller {

    @Override
    public void handleRequest(HttpServletRequest request, HttpServletResponse response)   {
        ...
    }
}

或者

@Componet("/welcome*")
public class WelcomeController implements HttpRequestHandler {

    @Override
    public void handleRequest(HttpServletRequest request, HttpServletResponse response)   {
        ...
    }
}

initHandlerAdapters 方法负责加载适配器,同样以 Bean 的形式保持在容器并执行初始化方法。如果程序员没有配置,那么 SpringMVC 也有默认提供的 HandlerAdapter。处理请求时,根据请求找到对应的处理器对象后,就会适配得到一个 HandlerAdapter,由 HandlerAdapter 执行处请求

SpringMVC 默认的适配器有:

  • RequestMappingHandlerAdapter:适配处理器是 HandlerMethod 对象
  • HandlerFunctionAdapter:适配处理器是HandlerFunction对象
  • HttpRequestHandlerAdapter:适配处理器是 HttpRequestHandler 对象
  • SimpleControerHandlerAdapter:适配处理器是 Controller 对象


父子容器

前面提到过,初始化 DispatcherServlet 时其内部会跟着创建一个 Spring 容器,那如果在 web.xml 中配置了两个不同的 DispatcherServlet,那么就会有两个分属不同 DispatcherServlet 的 Spring 容器

<!-- 第一个 DispatcherServlet -->
<servlet>
    <servlet-name>app1</servlet>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/spring1.xml</param-value>
        <load-on-startup>1</load-on-startup>
    </init-param>
</servlet>

<servlet-mapping>
    <servlet-name>app1</servlet-name>
    <servlet-pattern>/app1/*</servlet-pattern>
</servlet-mapping>

<!-- 第二个 DispatcherServlet -->
<servlet>
    <servlet-name>app2</servlet>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/spring2.xml</param-value>
        <load-on-startup>1</load-on-startup>
    </init-param>
</servlet>

<servlet-mapping>
    <servlet-name>app2</servlet-name>
    <servlet-pattern>/app2/*</servlet-pattern>
</servlet-mapping>

出现多个 DispatcherServlet 一般是解决多版本的问题,比如有一个 TestV1Controller 在 app1 这个 DispatcherServlet,现在多了一个升级版 TestV2Controller,就可以放在 app2,使用不同的映射路径

而有时候我们只希望区分不同的 Controller,而通用的 Service 并不需要在每个容器都保存一份,就可以配置父容器,将 Service 放在父容器。DispatcherServlet 初始化时会自动寻找是否存在父容器。

<web-app>

    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>

    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/root-spring.xml</param-value>
    </context-param>

    <servlet>
        <servlet-name>app1</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>/WEB-INF/spring1.xml</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>app1</servlet-name>
        <url-pattern>/app1/*</url-pattern>
    </servlet-mapping>

</web-app>

ContextLoaderListener 被配置到监听器列表,ServletContext 初始化时会使用 context-param 中参数名为 contextConfigLocation 设置的配置文件初始化父容器


SpringMVC 处理请求

SpringMVC 处理请求流程可分如下步骤:

  1. 根据路径找到对应的 Handler
  2. 解析参数并绑定
  3. 执行方法
  4. 解析返回值

1. 根据请求寻找 Handler

请求到来会执行 DispatcherServlet 的 getHandler 方法。遍历所有 HanlderMapping,每个 HandlerMapping 都是根据请求寻找 Handler,但寻找的方式不一样,比如 RequestMappingHandlerMapping 就是根据请求路径寻找 HandlerMethod, BeanNameUrlHandlerMapping 则是将请求路径映射到对应的 Bean 的名称。通过遍历 HandlerMapping,直到请求能找到对应的 Handler

不同的 HanlderMapping 所对应的 Handler 类型也不同,因此要找到对应类型的适配器。遍历所有 HandlerAdapter,如果找对适配的 HandlerAdapter 就返回,执行适配器的 handle 方法

2. 解析参数并执行方法

以 RequestMappingHandlerMapping 为例,Handler 的实际类型是 HandlerMethod,适配的是 RequestMappingHandlerAdapter。执行 invokeHandlerMethod 方法,解析 @initBinder 注解的方法并保存,解析 @SessionAttributes 注解设置的键值对,解析 @ModelAttribute 注解的方法,上述解析的结果将保存在 ModelFactory 对象,ModelFactory 用来初始化 Model 对象,初始化时将 @SessionAttributes 和 @ModelAttribute 设置的值保存到 Model 对象

接下来是创建参数解析器 argumentResolvers 和返回值解析器 returnValueHandlers。解析器有多种类型,对应不同的场景,例如使用 @PathVariable 注解传参就使用 PathVariableMethodArgumentResolver 解析器对象,返回值是 ModelAndView 对象则用 ModelAndViewMethodReturnValueHandler 解析器对象

获取方法参数,方法参数的类型是 MethodParameter,不仅包含了参数的名称,还包括参数的信息,比如是否有 @ReqeustParam 注解。遍历方法参数,并逐一用参数解析器遍历,找到适用的解析器进行解析,再根据参数名称从请求中获取参数值。如果定义了类型转换器,那就对参数类型进行转换。最后使用反射执行真正的方法逻辑

3. 解析返回值

拿到返回值后也是遍历寻找合适的返回值解析器进行处理,比如开发中经常会使用 @ResponseBody 注解返回 json,就会使用 RequestResponseBodyMethodProcessor 处理器进行处理,该处理器同时还承担了参数解析的作用。解析的过程中需要用到消息转换器 HttpMessageConverter,其作用是将方法的返回值转换为接收端(如浏览器)能接受的响应类型,SpringMVC 同样提供了默认的转换器。比如使用 @ResponseBody 注解的方法返回了 String 类型的返回值,那么就会遍历判断哪个消息转换器能处理 String 类型的返回值,在 RequestResponseBodyMethodProcessor 处理器中默认使用 StringHttpMessageConverter。接下来是内容协商,即是找到客户端能接受并且服务端能提供的内容类型,比如客户端希望优先返回 text/plain 类型的内容,而 StringHttpMessageConverter 能支持该类型,那么就使用 StringHttpMessageConverter 将方法返回值写入响应报文返回给客户端。如果我们希望方法直接返回对象类型并自动序列化为 json,那么就需要自定义消息转换器,此时 SpringMVC 将不再提供默认的转换器而是直接使用自定义的转换器,比如引入 MappingJackson2HttpMessageConverter 便能支持对象类型返回值转换为 json 并返回给客户端

如果不使用 @ResponseBody 注解,那么就会使用 ModelAndView 保存视图路径和数据。SpringMVC 同样提供了默认的视图解析器 ViewResolver,它会根据方法返回的 url 在 tomcat内部(不经由 DispatcherServlet 转发,而是使用原生 Servlet)进行一次转发请求到对应的视图文件如 jsp。如果 url 带有前缀 forward: 就表示这是一次转发请求,比如 forward:/app/test,SpringMVC 会去掉该前缀,使用 /app/test 重新交由 DispatcherServlet 转发交由对应处理器处理。如果 url 带有前缀 redirect:,比如 redirect:/test,SpringMVC 会去掉该前缀,给客户端的响应写上重定向头以及重定向地址即 /test,客户端会重新发送请求。转发和重定向的区别在于:转发请求是同一个,重定向则每次都是新的请求。转发时由于经过 DispatcherServlet,所以每次都会新建 Model,而重定向则会自动将 Model 中的参数拼接到重定向的 url


@EnableWebMvc

使用 @EnableWebMvc 注解可以帮助我们在代码中自定义 SpringMVC 配置,比如添加拦截器。使用 @EnableWebMvc 注解的配置类必须继承 WebMvcConfigurer 类

需要注意的是,@EnableWebMvc 是较旧的配置 SpringMVC 的方式。如果使用 SpringBoot,它提供了自动配置,通常不需要显式使用 @EnableWebMvc,只需要在配置文件配置即可

@Configuration
@EnableWebMvc
public class AppConfig implements WebMvcConfigurer {

    @Autowired
    private BeforMethodInteceptor beforMethodInteceptor;

    @Override
    public void addInterceptors(InterceptorRegistry registry) {    
        // 注册自定义拦截器,添加拦截路径和排除拦截路径
        registry.addInterceptor(beforMethodInteceptor) //添加拦截器
                   .addPathPatterns("/**") //添加拦截路径
                   .excludePathPatterns(  //添加排除拦截路径
                           "/index",
                           "/login",
                           ...
                           );
        super.addInterceptors(registry);        
    }

    @Override
    public void configureViewResolvers(ViewResolverRegistry registry) {
        // 配置视图解析器
        InternalResourceViewResolver viewResolver = new InternalResourceViewResolver();
        viewResolver.setPrefix("");
        viewResolver.setSuffix(".html");
        viewResolver.setCache(false);
        viewResolver.setContentType("text/html;charset=UTF-8");
        viewResolver.setOrder(0);        
        registry.viewResolver(viewResolver);
        super.configureViewResolvers(registry);
    }

    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        // 定义静态资源位置和 URL 映射规则
        // 例如,将所有以 /static/ 开头的 URL 映射到 /resources/ 目录下的静态资源
        registry.addResourceHandler("/static/**")
                .addResourceLocations("/resources/");
    }

    @Override
    public void configureMessageConverters(List<HttpMessageConverter<?>> converters) {
        // 添加 JSON 消息转换器
        converters.add(new MappingJackson2HttpMessageConverter());
    }

   @Override
    public void addCorsMappings(CorsRegistry registry) {
        // 跨域配置 
        registry.addMapping("/**")  // 配置允许跨域的路径
                .allowedOrigins("*")  // 配置允许访问的跨域资源的请求域名
                .allowedMethods("PUT,POST,GET,DELETE,OPTIONS")  // 配置允许访问该跨域资源服务器的请求方法
                .allowedHeaders("*"); // 配置允许请求 header 的访问
        super.addCorsMappings(registry);
    }
}

@EnableWebMvc 注解导入了 DelegatingWebMvcConfiguration 配置类,该类会将所有 WebMvcConfigurer 接口的实现类找到并保存起来。DelegatingWebMvcConfiguration 配置类还实现了 Aware 回调接口,因此会在 Spring 容器生命周期过程中调用回调接口,从而实现自定义配置

你好,我是 Kagol,个人公众号:
前端开源星球

自从 TinyVue 组件库去年开源以来,一直有小伙伴反馈我们的 UI 不够美观,风格陈旧,不太满足现阶段审美。

“TinyVue 给我的感觉就是一个没啥审美能力、但是很努力的老程序员开发的”

看到这个评价,我是哭笑不得,一方面对小伙伴们真诚、友好的反馈充满感激,另一方面也为我们没有做好 UI 感到惭愧。

于是我们和设计师同事携手一起,对 TinyVue 组件做了全面的 UI 升级,适配了一套更符合现代审美的设计规范:OpenTiny Design,这套全新的设计规范,是我们的设计师同事结合华为云的业务特点和最新的设计趋势打磨出来的,目前 TinyVue 所有组件均已支持 OpenTiny Design 设计规范。

当然这套设计规范也不是静止不变的,后续还是会不断迭代和优化,也欢迎广大的开发和设计师朋友给我们提出宝贵的意见。

访问 TinyVue 组件库官网即可进行体验:

https://opentiny.design/tiny-vue

整体组件效果

整体视觉风格以黑蓝为主,稳重又现代,并且更加圆润,看着非常舒服。

新旧效果对比

我们再来看下新旧效果对比。

按钮、表单类组件

除了颜色上的变化,按钮的变化比较明显,变成了全圆角,其他组件也更加圆润。

复选框按钮组件变化比较大,在右上角增加了对勾效果,勾选效果更明显,不容易和按钮混淆。

数字输入框组件的优化效果也很明显,原先细长细长的,感觉不太协调,优化之后更符合现代风格。

输入、下拉类组件

所有的输入框类的组件边框颜色都比之前淡一些,不会太突兀,并且也更圆润。

日期选择框是一个很复杂的组件,我们花了很多精力进行优化,很多都是细节上的打磨,虽然每个细节的优化都不起眼,但是所有细节优化合起来,整体给人的感觉就有很大的不同,大家可以体验下日期选择框这个组件。

https://opentiny.design/tiny-vue/zh-CN/os-theme/components/date-picker

弹窗组件

弹窗组件主要是整体宽度、圆角、阴影的调整,看起来调整的东西不多,但每一处调整都起了画龙点睛的效果。

警告组件

警告组件比较明显的变化是颜色和图标,颜色的层次更加分明,图标的表意也更加准确,比如警告图标,之前是圆形的,现在改成三角形,就更加符合大家的共识。

表格组件

表格组件看起来变化不大,但细看也有很多优化,比如整体线条颜色更浅,更能突出单元格中的核心内容,表头颜色和高度也有一定的调整。

其他组件

滑块组件的优化也非常明显,之前的滑块手柄给人一种很古老的感觉,难怪大家都说风格陈旧,现在改成圆形效果好多了,看起来就像是现代的风格。

大家觉得这次 TinyVue 的视觉升级效果怎么样呢?欢迎在评论区留言。

联系我们

GitHub:
https://github.com/opentiny/tiny-vue
(欢迎 Star ⭐)

官网:
https://opentiny.design/tiny-vue

B站:
https://space.bilibili.com/15284299

个人博客:
https://kagol.github.io/blogs

小助手微信:opentiny-official

公众号:OpenTiny

CountDownLatch
是 Java 并发包(
java.util.concurrent
)中的一个同步辅助类,它允许一个或多个线程等待一组操作完成。

一、设计理念

CountDownLatch
是基于 AQS(AbstractQueuedSynchronizer)实现的。其核心思想是
维护一个倒计数
,每次倒计数减少到零时,等待的线程才会继续执行。它的主要设计目标是允许多个线程协调完成一组任务。

1. 构造函数与计数器

public CountDownLatch(int count) {
    if (count < 0) throw new IllegalArgumentException("count < 0");
    this.sync = new Sync(count);
}

构造
CountDownLatch
时传入的
count
决定了计数器的初始值。该计数器控制了线程的释放。

2. AQS 支持的核心操作

AQS 是
CountDownLatch
的基础,通过自定义内部类
Sync
实现,
Sync
继承了 AQS 并提供了必要的方法。以下是关键操作:

  • acquireShared(int arg)
    : 如果计数器值为零,表示所有任务已完成,线程将获得许可。
  • releaseShared(int arg)
    : 每次调用
    countDown()
    ,会减少计数器,当计数器降到零时,AQS 将释放所有等待的线程。

3. 实现细节

  • countDown()
    :调用
    releaseShared()
    减少计数器,并通知等待线程。
  • await()
    :调用
    acquireSharedInterruptibly(1)
    ,如果计数器非零则阻塞等待。

二、底层原理

CountDownLatch
的核心是基于
AbstractQueuedSynchronizer
(AQS)来管理计数器状态的。AQS 是 JUC 中许多同步工具的基础,通过一个独占/共享模式的同步队列实现线程的管理和调度。
CountDownLatch
采用 AQS 的
共享锁机制
来控制多个线程等待一个条件。

1. AQS 的共享模式

AQS 设计了两种同步模式:
独占模式
(exclusive)和
共享模式
(shared)。
CountDownLatch
使用共享模式:

  • 独占模式
    :每次只能一个线程持有锁,如
    ReentrantLock
  • 共享模式
    :允许多个线程共享锁状态,如
    Semaphore

    CountDownLatch

CountDownLatch

await()

countDown()
方法对应于 AQS 的
acquireShared()

releaseShared()
操作。
acquireShared()
会检查同步状态(计数器值),若状态为零则立即返回,否则阻塞当前线程,进入等待队列。
releaseShared()
用于减少计数器并唤醒所有等待线程。

2. Sync 内部类的设计

CountDownLatch
通过一个私有的内部类
Sync
来实现同步逻辑。
Sync
继承自
AQS
,并重写
tryAcquireShared(int arg)

tryReleaseShared(int arg)
方法。

static final class Sync extends AbstractQueuedSynchronizer {
    Sync(int count) {
        setState(count);
    }

    protected int tryAcquireShared(int acquires) {
        return (getState() == 0) ? 1 : -1;
    }

    protected boolean tryReleaseShared(int releases) {
        // 自旋减计数器
        for (;;) {
            int c = getState();
            if (c == 0)
                return false;
            int nextc = c - 1;
            if (compareAndSetState(c, nextc))
                return nextc == 0;
        }
    }
}
  • tryAcquireShared(int)
    :当计数器为零时返回 1(成功获取锁),否则返回 -1(阻塞)。
  • tryReleaseShared(int)
    :每次
    countDown()
    减少计数器值,当计数器到达零时返回
    true
    ,唤醒所有阻塞线程。

3. CAS 操作确保线程安全

tryReleaseShared
方法使用 CAS(compare-and-set)更新计数器,避免了锁的开销。CAS 操作由 CPU 原语(如
cmpxchg
指令)支持,实现了高效的非阻塞操作。这种设计保证了
countDown()
的线程安全性,使得多个线程能够并发地减少计数器。

4. 内部的 ConditionObject

CountDownLatch
不支持复用,因为 AQS 的
ConditionObject
被设计为单一触发模式。计数器一旦降至零,
CountDownLatch
无法重置,只能释放所有线程,而不能再次设置初始计数器值。这就是其不可复用的根本原因。

三、应用场景

  1. 等待多线程任务完成

    CountDownLatch
    常用于需要等待一组线程完成其任务后再继续的场景,如批处理任务。
  2. 并行执行再汇总
    :在某些数据分析或计算密集型任务中,将任务分割成多个子任务并行执行,主线程等待所有子任务完成后再汇总结果。
  3. 多服务依赖协调
    :当一个服务依赖多个其他服务时,可以使用
    CountDownLatch
    来同步各个服务的调用,并确保所有依赖服务准备好之后再执行主任务。

四、示例代码

以下示例展示如何使用
CountDownLatch
实现一个并发任务等待所有子任务完成的机制。

import java.util.concurrent.CountDownLatch;

public class CountDownLatchExample {
    private static final int TASK_COUNT = 5;
    private static CountDownLatch latch = new CountDownLatch(TASK_COUNT);

    public static void main(String[] args) throws InterruptedException {
        for (int i = 0; i < TASK_COUNT; i++) {
            new Thread(new Task(i + 1, latch)).start();
        }
        
        // 主线程等待所有任务完成
        latch.await();
        System.out.println("所有任务已完成,继续主线程任务");
    }

    static class Task implements Runnable {
        private final int taskNumber;
        private final CountDownLatch latch;

        Task(int taskNumber, CountDownLatch latch) {
            this.taskNumber = taskNumber;
            this.latch = latch;
        }

        @Override
        public void run() {
            try {
                System.out.println("子任务 " + taskNumber + " 开始执行");
                Thread.sleep((int) (Math.random() * 1000)); // 模拟任务执行时间
                System.out.println("子任务 " + taskNumber + " 完成");
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            } finally {
                latch.countDown(); // 完成一个任务,计数器减一
            }
        }
    }
}

五、与其他同步工具的对比

1. CyclicBarrier

原理和用途

  • CyclicBarrier
    也允许一组线程相互等待,直到所有线程到达屏障位置(barrier point)。
  • 它适合用于
    多阶段任务

    分阶段汇聚
    ,如处理分块计算时每阶段汇总结果。

底层实现

  • CyclicBarrier
    内部通过
    ReentrantLock

    Condition
    实现,屏障次数可以重置,从而支持循环使用。

与 CountDownLatch 的对比

  • CyclicBarrier

    可复用性
    使其适合重复的同步场景,而
    CountDownLatch
    是一次性的。
  • CountDownLatch
    更灵活,允许任意线程调用
    countDown()
    ,适合分布式任务。
    CyclicBarrier
    需要指定的线程达到屏障。

2. Semaphore

原理和用途

  • Semaphore
    主要用于
    控制资源访问
    的并发数量,如限制数据库连接池的访问。

底层实现

  • Semaphore
    基于 AQS 的共享模式实现,类似于
    CountDownLatch
    ,但允许通过指定的“许可证”数量控制资源。

与 CountDownLatch 的对比

  • Semaphore
    可以动态增加/减少许可,而
    CountDownLatch
    只能递减。
  • Semaphore
    适合控制访问限制,而
    CountDownLatch
    用于同步点倒计数。

3. Phaser

原理和用途

  • Phaser

    CyclicBarrier
    的增强版,允许动态调整参与线程的数量。
  • 适合多阶段任务同步,并能随时增加或减少参与线程。

底层实现

  • Phaser
    内部包含一个计数器,用于管理当前阶段的参与线程,允许任务动态注册或注销。

与 CountDownLatch 的对比

  • Phaser
    更适合复杂场景,能够灵活控制阶段和参与线程;
    CountDownLatch
    的结构简单,只能用于一次性同步。
  • Phaser
    的设计更复杂,适合长时间、多线程协调任务,而
    CountDownLatch
    更适合简单任务等待。

4、总结

CountDownLatch
是一个轻量级、不可复用的倒计数同步器,适合简单的一次性线程协调。其基于 AQS 的共享锁实现使得线程等待和计数器更新具有高效的并发性。虽然
CountDownLatch
不具备重用性,但其设计简洁,尤其适合需要等待多线程任务完成的场景。

与其他 JUC 工具相比:

  • CyclicBarrier
    更适合多阶段同步、阶段性汇总任务。
  • Semaphore
    适合资源访问控制,具有可控的许可量。
  • Phaser
    灵活性更高,适合动态参与线程、复杂多阶段任务。

选择适合的同步工具,取决于任务的性质、线程参与动态性以及是否需要重用同步控制。

本文原文地址:
GoLang协程Goroutiney原理与GMP模型详解

什么是goroutine

Goroutine是Go语言中的一种轻量级线程,也成为协程,由Go运行时管理。它是Go语言并发编程的核心概念之一。Goroutine的设计使得在Go中实现并发编程变得非常简单和高效。

以下是一些关于Goroutine的关键特性:

  • 轻量级:Goroutine的创建和切换开销非常小。与操作系统级别的线程相比,Goroutine占用的内存和资源更少。一个典型的Goroutine只需要几KB的栈空间,并且栈空间可以根据需要动态增长。
  • 并发执行:Goroutine可以并发执行多个任务。Go运行时会自动将Goroutine调度到可用的处理器上执行,从而充分利用多核处理器的能力。
  • 简单的语法:启动一个Goroutine非常简单,只需要在函数调用前加上go关键字。例如,go myFunction()会启动一个新的Goroutine来执行myFunction函数。
  • 通信和同步:Go语言提供了通道(Channel)机制,用于在Goroutine之间进行通信和同步。通道是一种类型安全的通信方式,可以在不同的Goroutine之间传递数据。

什么是协程

协程(Coroutine)是一种比线程更轻量级的并发编程方式。它允许在单个线程内执行多个任务,并且可以在任务之间进行切换,而不需要进行线程上下文切换的开销。协程通过协作式多任务处理来实现并发,这意味着任务之间的切换是由程序显式控制的,而不是由操作系统调度的。

以下是协程的一些关键特性:

  • 轻量级:协程的创建和切换开销非常小,因为它们不需要操作系统级别的线程管理。
  • 非抢占式:协程的切换是显式的,由程序员在代码中指定,而不是由操作系统抢占式地调度。
  • 状态保存:协程可以在暂停执行时保存其状态,并在恢复执行时继续从暂停的地方开始。
  • 异步编程:协程非常适合用于异步编程,特别是在I/O密集型任务中,可以在等待I/O操作完成时切换到其他任务,从而提高程序的并发性和效率。

Goroutin就是Go在协程这个场景上的实现。

以下是一个简单的go goroutine例子,展示了如何使用协程:

package main

import (
	"fmt"
	"sync"
	"time"
)

// 定义一个简单的函数,模拟一个耗时操作
func printNumbers(wg *sync.WaitGroup) {
	defer wg.Done() // 在函数结束时调用Done方法
	for i := 1; i <= 5; i++ {
		fmt.Printf("Number: %d\n", i)
		time.Sleep(1 * time.Second) // 模拟耗时操作
	}
}

func main() {
	var wg sync.WaitGroup

	// 启动一个goroutine来执行printNumbers函数
	wg.Add(1)
	go printNumbers(&wg)

	// 主goroutine继续执行其他操作
	for i := 'A'; i <= 'E'; i++ {
		fmt.Printf("Letter: %c\n", i)
		time.Sleep(1 * time.Second) // 模拟耗时操作
	}

	// 等待所有goroutine完成
	wg.Wait()
}

我们定义了一个名为printNumbers的函数,该函数会打印数字1到5,并在每次打印后暂停1秒。然后,在main函数中,我们使用go关键字启动一个新的goroutine来执行printNumbers函数。同时,主goroutine继续执行其他操作,打印字母A到E,并在每次打印后暂停1秒。

需要注意的是,主goroutine和新启动的goroutine是并发执行的。为了确保所有goroutine完成,我们使用sync.WaitGroup来等待所有goroutine完成。我们在启动goroutine之前调用wg.Add(1),并在printNumbers函数结束时调用wg.Done()。最后,我们在main函数中调用wg.Wait(),等待所有goroutine完成。这样可以确保程序在所有goroutine完成之前不会退出。

协程是一种强大的工具,可以简化并发编程,特别是在处理I/O密集型任务时。

Goroutin实现原理

Goroutine的实现原理包括Goroutine的创建、调度、上下文切换和栈管理等多个方面。通过GPM模型和高效的调度机制,Go运行时能够高效地管理和调度大量的Goroutine,实现高并发编程。

Goroutine的创建

当使用go关键字启动一个新的Goroutine时,Go运行时会执行以下步骤:

  1. 分配G结构体:Go运行时会为新的Goroutine分配一个G结构体(G表示Goroutine),其中包含Goroutine的状态信息、栈指针、程序计数器等。
  2. 分配栈空间:Go运行时会为新的Goroutine分配初始的栈空间,通常是几KB。这个栈空间是动态增长的,可以根据需要自动扩展。
  3. 初始化G结构体:Go运行时会初始化G结构体,将Goroutine的入口函数、参数、栈指针等信息填入G结构体中。
  4. 将Goroutine加入调度队列:Go运行时会将新的Goroutine加入到某个P(Processor)的本地运行队列中,等待调度执行。

Goroutine的调度

Go运行时使用GPM模型(Goroutine、Processor、Machine)来管理和调度Goroutine。调度过程如下:

  • P(Processor):P是Go运行时的一个抽象概念,表示一个逻辑处理器。每个P持有一个本地运行队列,用于存储待执行的Goroutine。P的数量通常等于机器的CPU核心数,可以通过runtime.GOMAXPROCS函数设置。
  • M(Machine):M表示一个操作系统线程。M负责实际执行P中的Goroutine。M与P是一对一绑定的关系,一个M只能绑定一个P,但一个P可以被多个M绑定(通过抢占机制)。M的数量是由Go运行时系统动态管理和确定的。M的数量并不是固定的,而是根据程序的运行情况和系统资源的使用情况动态调整的。通过runtime.NumGoroutine()和runtime.NumCPU()函数,我们可以查看当前的Goroutine数量和CPU核心数。Go运行时对M的数量有一个默认的最大限制,以防止创建过多的M导致系统资源耗尽。这个限制可以通过环境变量GOMAXPROCS进行调整,但通常不需要手动设置。
  • G(Goroutine):代表一个goroutine,它有自己的栈,instruction pointer和其他信息(正在等待的channel等等),用于调度。
  • 调度循环:每个P会在一个循环中不断从本地运行队列中取出Goroutine,并将其分配给绑定的M执行。如果P的本地运行队列为空,P会尝试从其他P的本地运行队列中窃取Goroutine(工作窃取机制)。

    从上图中看,有2个物理线程M,每一个M都拥有一个处理器P,每一个也都有一个正在运行的goroutine。P的数量可以通过GOMAXPROCS()来设置,它其实也就代表了真正的并发度,即有多少个goroutine可以同时运行。图中灰色的那些goroutine并没有运行,而是出于ready的就绪态,正在等待被调度。P维护着这个队列(称之为runqueue),Go语言里,启动一个goroutine很容易:go function 就行,所以每有一个go语句被执行,runqueue队列就在其末尾加入一个goroutine,在下一个调度点,就从runqueue中取出(如何决定取哪个goroutine?)一个goroutine执行。

P的数量可以大于器的CPU核心数?

在Go语言中,P(Processor)的数量通常等于机器的CPU核心数,但也可以通过runtime.GOMAXPROCS函数进行调整。默认情况下,Go运行时会将P的数量设置为机器的逻辑CPU核心数。然而,P的数量可以被设置为大于或小于机器的CPU核心数,这取决于具体的应用需求和性能考虑。

调整P的数量,可以使用runtime.GOMAXPROCS函数来设置P的数量。例如:

package main

import (
	"fmt"
	"runtime"
	"sync"
)

func worker(id int, wg *sync.WaitGroup) {
	defer wg.Done()
	fmt.Printf("Worker %d starting\n", id)
	// 模拟工作负载
	for i := 0; i < 1000000000; i++ {
	}
	fmt.Printf("Worker %d done\n", id)
}

func main() {
	// 设置P的数量为机器逻辑CPU核心数的两倍
	numCPU := runtime.NumCPU()
	runtime.GOMAXPROCS(numCPU * 2)

	var wg sync.WaitGroup

	// 启动多个Goroutine
	for i := 1; i <= 10; i++ {
		wg.Add(1)
		go worker(i, &wg)
	}

	// 等待所有Goroutine完成
	wg.Wait()
	fmt.Println("All workers done")
}

在这个示例中,我们将P的数量设置为机器逻辑CPU核心数的两倍。这样做的目的是为了观察在不同P数量设置下程序的性能表现。

  • P的数量大于CPU核心数的影响
    • 上下文切换增加:当P的数量大于CPU核心数时,可能会导致更多的上下文切换。因为操作系统需要在有限的CPU核心上调度更多的线程(M),这可能会增加调度开销。
    • 资源竞争:更多的P意味着更多的Goroutine可以同时运行,但这也可能导致更多的资源竞争,特别是在I/O密集型任务中。过多的P可能会导致资源争用,反而降低程序的整体性能。
    • 并发性提高:在某些情况下,增加P的数量可以提高程序的并发性,特别是在存在大量阻塞操作(如I/O操作)的情况下。更多的P可以更好地利用CPU资源,减少阻塞时间。
  • P的数量小于CPU核心数的影响
    • CPU利用率降低:当P的数量小于CPU核心数时,可能会导致CPU资源未被充分利用。因为P的数量限制了同时运行的Goroutine数量,可能会导致某些CPU核心处于空闲状态。
    • 减少上下文切换:较少的P数量可以减少上下文切换的开销,因为操作系统需要调度的线程(M)数量减少。这可能会提高CPU密集型任务的性能。

选择合适的P数量选择合适的P数量需要根据具体的应用场景和性能需求进行调整。以下是一些建议:

  • CPU密集型任务:对于CPU密集型任务,通常将P的数量设置为等于或接近机器的逻辑CPU核心数,以充分利用CPU资源。
  • I/O密集型任务:对于I/O密集型任务,可以考虑将P的数量设置为大于CPU核心数,以提高并发性和资源利用率。
  • 性能测试和调优:通过性能测试和调优,找到最佳的P数量设置。可以尝试不同的P数量,观察程序的性能表现,选择最优的配置。

Goroutine的上下文切换

Goroutine的上下文切换由Go运行时的调度器管理,主要涉及以下步骤:

  • 保存当前Goroutine的状态:当一个Goroutine被挂起时,Go运行时会保存当前Goroutine的状态信息,包括程序计数器、栈指针、寄存器等。
  • 切换到新的Goroutine:Go运行时会从P的本地运行队列中取出下一个待执行的Goroutine,并恢复其状态信息。
  • 恢复新的Goroutine的状态:Go运行时会将新的Goroutine的状态信息加载到CPU寄存器中,并跳转到新的Goroutine的程序计数器位置,继续执行。

Goroutine什么时候会被挂起?Goroutine会在执行阻塞操作、使用同步原语、被调度器调度、创建和销毁时被挂起。Go运行时通过高效的调度机制管理Goroutine的挂起和恢复,以实现高并发和高性能的程序执行。了解这些挂起的情况有助于编写高效的并发程序,并避免潜在的性能问题。

  1. 阻塞操作

当Goroutine执行阻塞操作时,它会被挂起,直到阻塞操作完成。常见的阻塞操作包括:

  • I/O操作:如文件读写、网络通信等。
  • 系统调用:如调用操作系统提供的阻塞函数。
  • Channel操作:如在无缓冲Channel上进行发送或接收操作时,如果没有对应的接收者或发送者,Goroutine会被挂起。
  1. 同步原语

使用同步原语(如sync.Mutex、sync.WaitGroup、sync.Cond等)进行同步操作时,Goroutine可能会被挂起,直到条件满足。例如:

  • 互斥锁(Mutex):当Goroutine尝试获取一个已经被其他Goroutine持有的互斥锁时,它会被挂起,直到锁被释放。
  • 条件变量(Cond):当Goroutine等待条件变量时,它会被挂起,直到条件变量被通知。
  1. 调度器调度

Go运行时的调度器会根据需要挂起和恢复Goroutine,以实现高效的并发调度。调度器可能会在以下情况下挂起Goroutine:

  • 时间片用完:Go调度器使用协作式调度,当一个Goroutine的时间片用完时,调度器会挂起该Goroutine,并调度其他Goroutine执行。
  • 主动让出:Goroutine可以通过调用runtime.Gosched()主动让出CPU,调度器会挂起该Goroutine,并调度其他Goroutine执行。
  1. Goroutine的创建和销毁
  • 创建:当一个新的Goroutine被创建时,它会被挂起,直到调度器将其调度执行。
  • 销毁:当一个Goroutine执行完毕或被显式终止时,它会被挂起并从调度器中移除。

Goroutine的栈管理

Goroutine的栈空间是动态分配的,可以根据需要自动扩展。Go运行时使用分段栈(segmented stack)或连续栈(continuous stack)来管理Goroutine的栈空间:

  • 分段栈:在早期版本的Go中,Goroutine使用分段栈。每个Goroutine的栈由多个小段组成,当栈空间不足时,Go运行时会分配新的栈段并链接到现有的栈段上。
  • 连续栈:在Go 1.3及以后的版本中,Goroutine使用连续栈。每个Goroutine的栈是一个连续的内存块,当栈空间不足时,Go运行时会分配一个更大的栈,并将现有的栈内容复制到新的栈中。

书接上回,我们继续来分享一些关于时间转换的常用扩展方法。

01
、时间转日期时间 TimeOnly

该方式是把TimeOnly类型转为DateTime类型,其中日期部分使用系统当前日期,时间部分则使用TimeOnly,具体代码如下:

//时间转日期时间,默认使用当前日期+时间转为日期时间格式
public static DateTime ToDateTime(this TimeOnly timeOnly)
{
    return DateOnly.FromDateTime(DateTime.Now).ToDateTime(timeOnly);
}

02
、日期+时间转为日期时间 TimeOnly

该方法是直接对TimeOnly时间进行扩展,取用其时间,然后补全指定DateOnly日期,最后转为DateTime,代码如下:

//日期+时间转为日期时间
public static DateTime ToDateTime(this TimeOnly timeOnly, DateOnly dateOnly)
{
    return dateOnly.ToDateTime(timeOnly);
}

03
、日期时间中日期部分+时间转日期时间 TimeOnly

该方法是对TimeOnly时间进行扩展,取其时间,然后补全指定DateTime中的日期部分,最后再转为DateTime,代码如下:

//日期时间中日期部分+时间转日期时间格式
public static DateTime ToDateTime(this TimeOnly timeOnly, DateTime dateTime)
{
    return DateOnly.FromDateTime(dateTime).ToDateTime(timeOnly);
}

04
、日期转日期时间 DateOnly

该方式是把DateOnly类型转为DateTime类型,其中日期部分使用DateOnly,时间部分则使用系统当前时间,具体代码如下:

//日期转日期时间,日期+默认使用当前时间转为日期时间格式
public static DateTime ToDateTime(this DateOnly dateOnly)
{
    return dateOnly.ToDateTime(TimeOnly.FromDateTime(DateTime.Now));
}

05
、日期+日期时间中时间部分转日期时间 DateOnly

该方法是对DateOnly日期进行扩展,取其日期,然后补全指定DateTime中的时间部分,最后再转为DateTime,代码如下:

//日期+日期时间中时间部分转日期时间
public static DateTime ToDateTime(this DateOnly dateOnly, DateTime dateTime)
{
    return dateOnly.ToDateTime(TimeOnly.FromDateTime(dateTime));
}

06
、日期时间中日期部分+时间转日期时间 DateTime

该方法是对DateTime日期时间进行扩展,取其日期部分,然后补全指定TimeOnly时间,最后再转为DateTime,代码如下:

//日期时间中日期部分+时间转日期时间
public static DateTime ToDateTime(this DateTime dateTime, TimeOnly timeOnly)
{
    return DateOnly.FromDateTime(dateTime).ToDateTime(timeOnly);
}

07
、日期+日期时间中时间部分转为日期时间 DateTime

该方法是对DateTime日期时间进行扩展,取其时间部分,然后补全指定DateOnly日期,最后再转为DateTime,代码如下:

//日期+日期时间中时间部分转为日期时间
public static DateTime ToDateTime(this DateTime dateTime, DateOnly dateOnly)
{
    return dateOnly.ToDateTime(TimeOnly.FromDateTime(dateTime));
}

08
、日期时间转日期 DateTime

该方法是对DateTime日期时间进行扩展,取其日期部分转为DateOnly,代码如下:

//日期时间转日期,保留日期时间中日期部分
public static DateOnly ToDateOnly(this DateTime dateTime)
{
    return DateOnly.FromDateTime(dateTime);
}

09
、日期时间转时间 DateTime

该方法是对DateTime日期时间进行扩展,取其时间部分转为TimeOnly,代码如下:

//日期时间转时间,保留日期时间中时间部分
public static TimeOnly ToTimeOnly(this DateTime dateTime)
{
    return TimeOnly.FromDateTime(dateTime);
}

上面的这些扩展方法虽然大多都是简单调用原生方法,但是通过扩展方法方式提供出来后的确在编码上提升了一些效率,代码也会根据简洁。

10
、代码结构设计与组织

代码结构的设计和组织是软件开发过程中重要的一环,它将直接影响代码的可读性、可维护性、扩展性、测试性和团队协作的效率。

到目前为止我们关于时间的扩展方法已经有接近30个方法了,后面还有很多,目前都是放在DateTimeExtension类下面,如下图:

到这里已经能感受到代码结构显得很混乱了,直观感觉就是可读性差,没有结构化必然会导致扩展困难。

可能会有人提出不同观点,这些不就是很多静态方法吗,只有排版整齐就行了,其实不然,我们可以借助一些小技巧把方法集合结构化的管理起来。

结构化的管理一种实现方式就行——分类。下面我们就对现有代码进行分类。

分类是一门技术活,如何选择分类标准很关键,比如我们这里可以根据入参类型分为针对long类型转换、针对DateTime类型转换、针对string类型转换;也可以根据功能分类比如时间和时间戳互相转换是一类,时间和字符串互相转换是一类,DateTime与DateOnly和TimeOnly互相转换是一类等等分类方式。

1、分大类

我的思路是这样的,首先通过部分类partial把DateTimeExtension根据入参类型分成几个大类。

代码整理后效果如下:

2、分小类

分完大类后发现long类型中方法还是很大,因此我们继续对其进行分类,我们根据功能不同分为两类:转为本地日期时间和转为UTC日期时间。我们可以使用代码折叠的预处理指令#region和#endregion来处理处理小分类。

代码整理以后效果如下:

从一开始一堆方法到现在结构层次已经非常清晰了,阅读起来也非常方便,后期维护扩展就可以很容易的快速找到相应地方处理。

11
、单元测试

作为一个开源代码,我们首要任务应该保证代码正确性,因此单元测试是必不可少的。单元测试不但可以保证我们代码的正确性,还可以促使我们代码写的跟健壮。

单元测试我们以同样的分类方式进行代码组织,代码大致如下:

因为具体的测试用例都比较简单,这里就不拿出来讲解了。

测试用例编写的越完善,我们代码就越可靠,因此我们在编写单元测试时候,要尽可能覆盖所有逻辑,要尽可能覆盖到一些特例情况,我们想的越多代码质量才能越高。

12
、文档

作为一个开源代码,还需要一个好的文档,这样别人才能轻松使用,目前文档还是缺失的,后续我将陆续添加上。

当代码结构设计与组织、单元测试、文档这三部分都做好了,我感觉这个开源代码就达到开源给别人的最低要求了。后面的开源代码我都将围绕这三部分展开,希望可以给大家分享一些高质量的开源代码。

稍晚些时候我会把库上传至Nuget上,大家可以搜索Ideal.Core.Common直接使用。


:测试方法代码以及示例源码都已经上传至代码库,有兴趣的可以看看。
https://gitee.com/hugogoos/Ideal