1.ZMQ源码详细解析 之 进程内通信流程
2.干掉if else后，码设代码看起来爽多了！码设
3.Spring中ApplicationListener和ApplicationContext的码设使用
4.Vert.x 源码解析(4.x)——Context源码解析
5.Qt项目多语言文件读写，格式化，码设设计经验分享
6.Application中的 Context 和 Activity 中的Context区别

ZMQ源码详细解析 之 进程内通信流程

       ZMQ进程内通信流程解析

       ZMQ的码设核心进程内通信原理相当直接，它利用线程间的码设loaddll od 源码两个队列（我称为pipe）进行消息交换。每个线程通过一个队列发送消息，码设从另一个队列接收。码设ZMQ负责将pipe绑定到对应线程，码设并在send和recv操作中通过pipe进行数据传输，码设非常简单。码设

       我们通过一个示例程序来理解源码的码设工作流程。程序首先创建一个简单的码设hello world程序，加上sleep是码设为了便于分析流程。程序从`zmq_ctx_new()`开始，码设这个函数创建了一个上下文（context），这是ZMQ操作的起点。

       在创建socket时，如`zmq_socket(context, ZMQ_REP)`，实际调用了`ctx->create_socket`，socket类型决定了其特性。rep_t是基于router_t的特化版本，主要通过限制router_t的某些功能来实现响应特性。socket的嗮软源码创建涉及到诸如endpoint、slot和 mailbox等概念，它们在多线程环境中协同工作。

       进程内通信的建立通过`zmq_bind(responder, "inproc://hello")`来实现，这个端点被注册到上下文的endpoint集合中，便于其他socket找到通信通道。zmq的优化主要集中在关键路径上，避免对一次性操作过度优化。

       接下来的recv函数是关键，即使没有连接，它也会尝试接收消息。`xrecv`函数根据进程状态可能阻塞或返回EAGAIN。recv过程涉及`msg_t`消息的处理，以及与`signaler`和`mailbox`的交互，这些组件构成了无锁通信的核心。

       发送端通过`connect`函数建立连接，创建连接通道，并将pipe关联到socket。这个过程涉及无锁队列的管理，如ypipe_t和pipe_t，以及如何均衡发送和接收。

       总结来说，ZMQ进程内通信的核心是通过管道、队列和事件驱动机制，量群源码实现了线程间的数据交换。随着对ZMQ源码的深入，会更深入理解这些基础组件的设计和工作原理。

干掉if else后，代码看起来爽多了！

       今天，我们来深入剖析Mybatis框架中的设计模式，看看它如何巧妙地摆脱if/else的困扰，展现其独特魅力！

       Mybatis庞大的2万多行源码中，巧妙运用了多种设计模式来优化工程结构，如创建型模式的工厂设计，如SqlSessionFactory的构建。它通过SqlSessionFactory工厂模式，为我们获取会话提供统一接口，每次数据库操作都会通过这个工厂开启新的会话，其中包含了数据源配置、事务处理和SQL执行器的构建。

       另外，Configuration作为单例配置类，采用单例模式确保全局唯一，整合了映射、缓存等众多配置，YK源码网并在SqlSessionFactoryBuilder构建阶段初始化。ErrorContext、LogFactory和Configuration也是采用类似的单例模式，为框架的稳定运行提供支持。

       建造者模式在Mybatis中体现在如XMLConfigBuilder等类，通过逐步构建对象，避免了直接设置属性，保持了代码的清晰和可维护性。日志框架的适配则体现了适配器模式，通过统一接口让不同框架能无缝协作，如对Log4j、Log4j2和Slf4J等的适配。

       代理模式在MapperProxy的实现中尤为显著，它作为DAO接口的代理，统一了CRUD方法的调用，简化了业务逻辑。此外，组合模式在SQL配置中体现，通过SqlNode接口构建SQL规则树，组合出各种复杂场景。

       行为型模式如模板模式和策略模式在Mybatis中也大显身手，BaseExecutor定义了查询和修改的通用流程，而多类型处理器策略模式则通过TypeHandler实现了不同类型数据的雷付费源码处理策略。

       迭代器模式在PropertyTokenizer中体现，用于对象关系的解析，提升了代码的灵活性。总之，Mybatis巧妙地运用了约种设计模式，优化了代码结构，使得代码更加简洁和高效。

       深入研究源码不仅有助于理解框架工作原理，还能提升技术理解和实践能力，是成为高级工程师和架构师的重要基石。通过学习这些优秀的设计实践，我们可以更好地应对复杂的技术挑战。

Spring中ApplicationListener和ApplicationContext的使用

       关于Spring的源码相关功能

1引入ApplicationContext

       ApplicationContext是Spring的一个核心接口,允许容器通过应用程序上下文环境创建,获取,管理bean.

publicinterfaceApplicationContextextendsEnvironmentCapable,ListableBeanFactory,HierarchicalBeanFactory,MessageSource,ApplicationEventPublisher,ResourcePatternResolver{ /***Returntheuniqueidofthisapplicationcontext.*@returntheuniqueidofthecontext,or{ @codenull}ifnone*/@NullableStringgetId();/***Returnanameforthedeployedapplicationthatthiscontextbelongsto.*@returnanameforthedeployedapplication,ortheemptyStringbydefault*/StringgetApplicationName();/***Returnafriendlynameforthiscontext.*@returnadisplaynameforthiscontext(never{ @codenull})*/StringgetDisplayName();/***Returnthetimestampwhenthiscontextwasfirstloaded.*@returnthetimestamp(ms)whenthiscontextwasfirstloaded*/longgetStartupDate();/***Returntheparentcontext,or{ @codenull}ifthereisnoparent*andthisistherootofthecontexthierarchy.*@returntheparentcontext,or{ @codenull}ifthereisnoparent*/@NullableApplicationContextgetParent();AutowireCapableBeanFactorygetAutowireCapableBeanFactory()throwsIllegalStateException;}

       ApplicationContext提供的功能:

       访问应用程序组件的Bean工厂方法.从org.springframework.beans.factory.ListableBeanFactory继承而来.

publicinterfaceListableBeanFactoryextendsBeanFactory{ ......}

       通用方式加载文件资源的能力.从org.springframework.core.io.support.ResourcePatternResolver继承而来.

packageorg.springframework.core.io.support;importjava.io.IOException;importorg.springframework.core.io.Resource;importorg.springframework.core.io.ResourceLoader;publicinterfaceResourcePatternResolverextendsResourceLoader{ StringCLASSPATH_ALL_URL_PREFIX="classpath*:";Resource[]getResources(Stringvar1)throwsIOException;}

       向注册监听器发布事件的能力.从org.springframework.context.ApplicationEventPublisher继承而来.

@FunctionalInterfacepublicinterfaceApplicationEventPublisher{ defaultvoidpublishEvent(ApplicationEventevent){ publishEvent((Object)event);}voidpublishEvent(Objectevent);}

       解析消息的能力,支持国际化.从org.springframework.context.MessageSource继承而来.

publicinterfaceMessageSource{ @NullableStringgetMessage(Stringcode,@NullableObject[]args,@NullableStringdefaultMessage,Localelocale);StringgetMessage(Stringcode,@NullableObject[]args,Localelocale)throwsNoSuchMessageException;StringgetMessage(MessageSourceResolvableresolvable,Localelocale)throwsNoSuchMessageException;}

       从父上下文继承,后代上下文中的定义总是优先级.单个父上下文可以被整个web应用程序使用，而每个servlet都有自己独立于任何其他servlet的子上下文.

2关于ApplicationListener的说明2.1ApplicationListener简介

       ApplicationContext事件机制是属于设计模式中的观察者设计模式,通过ApplicationEvent类和ApplicationListener接口实现事件处理.

       当容器中有一个ApplicationListener对象,当ApplicationContext发布ApplicationEvent事件时,ApplicationListener对象会被自动触发,需要由程序来控制.此外Spring中也内置了一下事件.

内置事件说明ContextRefreshedEventApplicationContext被初始化或刷新时，该事件被发布。这也可以在ConfigurableApplicationContext接口中使用refresh()方法来发生。此处的初始化是指：所有的Bean被成功装载，后处理Bean被检测并激活，所有SingletonBean被预实例化，ApplicationContext容器已就绪可用ContextStartedEventConfigurableApplicationContext（ApplicationContext子接口）接口中的start()方法启动ApplicationContext时，该事件被发布。你可以调查你的数据库，或者你可以在接受到这个事件后重启任何停止的应用程序ContextStoppedEventConfigurableApplicationContext接口中的stop()停止ApplicationContext时，发布这个事件。你可以在接受到这个事件后做必要的清理的工作ContextClosedEventConfigurableApplicationContext接口中的close()方法关闭ApplicationContext时，该事件被发布。一个已关闭的上下文到达生命周期末端；它不能被刷新或重启RequestHandledEvent是web-specific事件，告诉所有beanHTTP请求已经被服务处理。只能应用于使用DispatcherServlet的Web应用。在使用Spring作为前端的MVC控制器时，当Spring处理用户请求结束后，系统会自动触发该事件2.2ApplicationListener案列1准备一个SpringBoot环境2创建一个自定义的监听器@ComponentpublicclassDemoApplicationListenerimplementsApplicationListener<ContextRefreshedEvent>{ @OverridepublicvoidonApplicationEvent(ContextRefreshedEventevent){ System.out.println(event);System.out.println("TestApplicationListener............................");}}

       根据上述可知,ContextRefreshedEvent内置事件,是ApplicationContext被初始化或刷新时会发布,即监听器可以收到回调信息.

3启动项目,查看日志3关于ApplicationContext的说明3.1ApplicationContext的简介

       从上述可知ApplicationContext具有发布事件的能力,是从ApplicationEventPublisher接口继承来的.而Spring中的事件使用,需要继承ApplicationEvent类或ApplicationContextEvent抽象类,抽象类中只有一个构造函数，且带有一个Object类型的参数作为事件源，且该事件源不能为null，因此我们需要在自己的构造函数中执行super(Object)。

publicclassEventObjectimplementsjava.io.Serializable{ privatestaticfinallongserialVersionUID=L;/***TheobjectonwhichtheEventinitiallyoccurred.*/protectedtransientObjectsource;/***ConstructsaprototypicalEvent.**@paramsourceTheobjectonwhichtheEventinitiallyoccurred.*@exceptionIllegalArgumentExceptionifsourceisnull.*/publicEventObject(Objectsource){ if(source==null)thrownewIllegalArgumentException("nullsource");this.source=source;}....}3.2ApplicationContext的案列3.2.1准备一个SpringBoot环境@SpringBootApplicationpublicclassApplication{ publicstaticvoidmain(String[]args){ SpringApplication.run(Application.class,args);testEvent();}//@Bean//publicFeignInterceptorfeignInterceptor(){ //returnnewFeignInterceptor();//}//测试事件publicstaticvoidtestEvent(){ ApplicationContextcontext=newAnnotationConfigApplicationContext(EventConfig.class);DemoEventdemoEvent=newDemoEvent(context,"小明",);context.publishEvent(demoEvent);}}3.2.2创建一个自定义的监听器@ComponentpublicclassDemo2ApplicationListenerimplementsApplicationListener<ApplicationEvent>{ @OverridepublicvoidonApplicationEvent(ApplicationEventevent){ //针对自定义事件做处理if(eventinstanceofDemoEvent){ System.out.println(event);DemoEventdemoEvent=(DemoEvent)event;System.out.println("姓名:"+demoEvent.getUsername()+",年龄:"+demoEvent.getAge());System.out.println("自定义DemoEvent事件............................");}}}3.2.3创建一个自定义的事件publicclassDemoEventextendsApplicationEvent{ privateStringusername;privateintage;/***CreateanewApplicationEvent.**@paramsourcetheobjectonwhichtheeventinitiallyoccurred(never{ @codenull})*/publicDemoEvent(Objectsource,Stringusername,intage){ super(source);this.username=username;this.age=age;}publicStringgetUsername(){ returnusername;}publicvoidsetUsername(Stringusername){ this.username=username;}publicintgetAge(){ returnage;}publicvoidsetAge(intage){ this.age=age;}}3.2.4启动项目,查看日志

Vert.x 源码解析(4.x)——Context源码解析

       Vert.x 4.x 源码深度解析：Context核心概念详解

       Vert.x 通过Context这一核心机制，解决了多线程环境下的资源管理和状态维护难题。Context在异步编程中扮演着协调者角色，确保线程安全的资源访问和有序的异步操作。本文将深入剖析Context的源码结构，包括其接口设计、关键实现以及在Vert.x中的具体应用。

       Context源代码解析

       Context接口定义了基础的事件处理功能，如立即执行和阻塞任务。ContextInternal扩展了Context，包含内部方法和功能，通常开发者无需直接接触，如获取当前线程的Context。在vertx的beginDispatch和endDispatch方法中，Context的切换策略取决于线程类型，Vertx线程会使用上下文切换，而非Vertx线程则依赖ThreadLocal。

       ContextBase是ContextInternal的实现类，负责执行耗时任务，内部包含TaskQueue来管理任务顺序。WorkerContext和EventLoopContext分别对应工作线程和EventLoop线程的执行策略，它们通过execute()、runOnContext()和emit()方法处理任务，同时监控性能。

       Context的创建和获取贯穿于Vert.x的生命周期，它在DeploymentManager的doDeploy方法中被调用，如NetServer和NetClient等组件的底层实现也依赖于Context来处理网络通信。

       额外说明

       Context与线程并非直接绑定，而是根据场景动态管理。部署时创建新Context，非部署时优先获取Thread和ThreadLocal中的Context。当执行异步任务时，当前线程的Context会被暂时替换，任务完成后才恢复。源码中已加入详细注释，如需获取完整注释版本，可联系作者。

       Context的重要性在于其在Vert.x的各个层面如服务器部署、EventBus通信中不可或缺，它负责维护线程同步与异步任务的执行顺序，是异步编程中不可或缺的基石。理解Context的实现，有助于更好地利用Vert.x进行高效开发。

Qt项目多语言文件读写，格式化，设计经验分享

       在这个Qt开发的多语言世界里，我们探讨如何巧妙地运用lconvert、lupdate和lreleaser这三个关键工具，轻松管理多语言文件的读写和格式化。首先，让我们深入理解ts文件，它是Qt项目的翻译基石，其结构精巧：包含文件信息、context（类间的翻译桥梁）以及message（每条翻译的源代码和目标语言文本，以fileInfo, source, translation的形式呈现）。

       通过QObject::tr函数，我们可以轻松实现字符串的本地化，lupdate工具则负责从源代码中提取并生成.ts（xml）文件，这个过程至关重要，它能让我们的翻译工作自动化，节省大量编辑时间。编辑ts文件时，linguist或HTML编辑器是不错的选择。然而，处理重复字符串和处理.ui文件内容时，我们需要格外小心，确保翻译的准确性和一致性。

       在项目运行时，ts文件的管理和处理需要精确无误。lreleaser生成的qm文件是关键，它将.ts文件中的信息整合到应用程序中。格式化问题和重复行是常见的挑战，这时lconvert工具就派上用场，通过添加参数如"-locations none"，可以消除行号，优化git的合并和diff体验，让代码管理更加顺畅。

       对于不熟悉xml格式的翻译团队，我们可以引入xlsx模板，便于原型图预翻译导入，简化导入过程。类间翻译的差异，可以通过关联类名或自定义宏定义来统一处理，确保项目的全局一致性。在设计策略上，为每个模块和语言创建独特的标识，以便于选择和控制多语言文件。此外，将ts文件的读写操作封装成类，通过并发执行，可以简化入口点和管理流程，提升效率。

       最后，lconvert的强大功能在于优化代码结构，帮助我们遵循规则读取数据，确保输出格式的一致性。在这个过程中，我们期待您的宝贵意见和建议，共同推动Qt项目的多语言开发更上一层楼。让我们一起探索Qt语言世界的无限可能！

Application中的 Context 和 Activity 中的Context区别

        Context在我们开发中经常用到，不管是Framework提供给我们的四大组件，还是应用级别的Application，还是负责表现层的View相关类，甚至连我们很多时候创建的实体类都会需要持有一个Context的引用。那么Context到底是什么呢？

        建议看这个： /p/bde4cb

        Context英文释义是当前上下文，或者当前场景上，

        官方文档：Context

        public abstractclass Context extends Object

        Interface to globalinformation about an application environment. This is an abstract class whoseimplementation is provided by the Android system. It allows access toapplication-specific resources and classes, as well as up-calls forapplication-level operations such as launching activities, broadcasting andreceiving intents, etc.

        由官方文档，我们可以知道：

        1.该类是一个抽象（abstract class）类；

        2.它描述的是一个应用程序环境的信息，即上下文；

        3.通过它（Context）我们可以获取应用程序的资源和类，也包括一些应用级别的操作（例如，启动 Activity,广播和服务等）;

        前面我们讲过 Context 是一个抽象类，通过 Context我们可以获取应用程序的资源和类，调用它们的方法，那么具体定义的方法有哪些呢？我们来看一下 Context 的源码：

        源码里的方法太多了，总共 行。我们从以上部分源码看到了熟悉的对象---Application、Activity、Service、Broadcast、这些对象和 Context 的关系到底是什么呢？我们看一下官方文档可知：

        1.Acitiivity 继承自ContextThemeWrapper--->再继承ContextWrapper--->Context。

        2.Appliction 、Service继承自ContextWrapper--->再继承Context。

        3.Application、Service 和 Activity 最终都是继承自Context，所以它们是同一个上下文。

        通过以上的继承关系，我们就可以知道，Context的具体作用会包括：

        - 启动一个新的Activity

        - 启动和停止Service

        - 发送广播消息(Intent)

        - 注册广播消息(Intent)接收者

        - 可以访问APK中各种资源，如Resources和AssetManager

        - 创建View

        - 访问Package的相关信息

        - APK的各种权限管理

        由上面分析的继承关系，我们可以知道，Context创建的时机有三个：

        ①创建Application 对象时， 而且整个App共一个Application对象；

        ②创建Service对象时；

        ③创建Activity对象时；

        所以应用程序App共有的Context数目公式为：

        Service个数 + Activity个数 + 1（Application对应的Context实例）

        如上，Android中context可以作很多操作，但是最主要的功能是加载和访问资源。在android中常用的context有两种，一种是application context，一种是activity context，通常我们在各种类和方法间传递的是activity context。

        两者的区别：

        this是Activity 的实例，扩展了Context，其生命周期是Activity 创建到销毁。getApplicationContext()返回应用的上下文，生命周期是整个应用，应用摧毁它才被摧毁。Activity.this的context 返回当前activity的上下文，属于activity ，activity摧毁时被摧毁。

        使用Context时最需要注意的一个点就是，使用了不正确的context，比如有一个全局的数据操作类用到了context，这个时候就要getApplicationContext 而不是用ACtivity，如果在这个全局操作中引用的是Activity的context，那么就会一直引用Activity的资源，导致GC无法回收这部分内存，从而最终导致了内存泄漏。

        内存泄漏是开发中常见的错误之一，能不能发现取决于开发者的经验，当然了我们也会依赖现有的内存泄漏库，但是如果我们在开发的源头减少内存泄漏的概率，那么后期的工作会少很多。

        以下是避免context相关的内存泄露，给出的几点建议：

        以下的表列举的是三种Context对象的对应使用场景：

        从表中可以看到，和UI相关的都使用Activity的Context对象。

        小结：如上分析，Context在对应开发里的来源就是三个——Activity、Service和Appliaction，那么我们该如何选择使用哪一个Context对象呢？一个比较简单的方法是，当你无法确定使用某个Context对象是否会造成长引用导致内存泄漏时，那么就使用Appliaction的Context对象，因为Appliaction存在于整个应用的生命周期内。

        在实际开发中，我们往往会为项目定义一个Applictaion，然后在AndroidMainfest.xml文件中进行注册，

        而且在自定义Application往往会定义好一个静态方法，用以全局获取application实例：

        Activity和Application都是Context的子类，但是他们维护的生命周期不一样。前者维护一个Acitivity的生命周期，所以其对应的Context也只能访问该activity内的各种资源。后者则是维护一个Application的生命周期。

        1.如何判断context是属于哪个activity？

        2.全局不同如何获取对应的context？

        静态加载一个Fragment，在onCreateView()方法中通过getActivity获取上下文实例：

        3.四大组件可以像普通Java类一样，采用new的方式实例化吗？

        Android程序不像Java程序一样，随便创建一个类，写个main()方法就能运行，Android应用模型是基于组件的应用设计模式，组件的运行要有一个完整的Android工程环境，在这个环境下，Activity、Service等系统组件才能够正常工作，而这些组件并不能采用普通的Java对象创建方式，new一下就能创建实例了，而是要有它们各自的上下文环境，也就是我们这里讨论的Context。可以这样讲，Context是维持Android程序中各组件能够正常工作的一个核心功能类。