Java

Spring MVC 是 Spring Framework 中负责处理 HTTP 请求的 Web 框架，实现了 MVC 设计模式。它是一个功能模块，而非独立框架。 Spring MVC 与 Spring Boot 的关系 这两者经常被混淆，理清层次是关键。 层次关系 Spring Framework（基础框架） └── Spring MVC（Web 层模块，属于 Spring Framework 的一部分） Spring Boot（构建在 Spring Framework 之上的脚手架/工具） └── spring-boot-starter-web（包含 Spring MVC + 内嵌 Tomcat + Jackson） Spring MVC 是 Spring Framework 中负责处理 HTTP 请求的 Web 框架，实现了 MVC 设计模式。它是一个功能模块。 Spring Boot 是一个构建工具/脚手架，它并不替代 Spring MVC，而是让配置 Spring MVC（以及其他模块）变得更简单。 对比：传统 Spring MVC vs Spring Boot 方面 传统 Spring MVC Spring Boot 配置方式 XML（web.xml、applicationContext.xml）或 Java Config 自动配置，几乎零 XML 部署方式 打包为 WAR，部署到外部 Tomcat 打包为可执行 JAR，内嵌 Tomcat 依赖管理 手动指定每个依赖及版本，容易版本冲突 Starter 统一管理，版本经过验证 启动入口 通过 Servlet 容器启动 @SpringBootApplication 主类 + main() 方法 学习曲线 较陡，需理解大量 XML 配置 较平，约定优于配置 底层请求处理链路 无论是传统 Spring MVC + WAR，还是 Spring Boot + JAR，处理 HTTP 请求的调用链从未改变： ...

SecurityFilterChain SecurityFilterChain 是 Spring Security 的核心抽象，代表一条作用于 HTTP 请求的安全过滤器链。每个进入应用的请求都会依次经过链中的若干 Filter，完成认证（Authentication）、授权（Authorization）、CSRF 防护、会话管理等工作。 底层机制：从 Servlet Filter 到 Spring Security Servlet 规范本身有 Filter 接口和 FilterChain 接口。Spring Security 通过以下两层代理接入这套机制： DelegatingFilterProxy：在 Servlet 容器（Tomcat）层面注册的 Filter，作用是把请求桥接到 Spring 容器中的 Bean。它本身不做安全逻辑，只是一个"入口代理"。 FilterChainProxy：Spring 容器中的真正实现，也是一个特殊的 Filter。它持有所有注册的 SecurityFilterChain Bean，收到请求后，按顺序匹配第一条能处理该 URL 的链，然后依次执行链中的每个 Filter。 HTTP 请求 → Tomcat FilterChain → DelegatingFilterProxy（Servlet Filter，桥接到 Spring） → FilterChainProxy（Spring Bean） → SecurityFilterChain 1（匹配 /api/**） UsernamePasswordAuthenticationFilter BearerTokenAuthenticationFilter ExceptionTranslationFilter AuthorizationFilter ... → SecurityFilterChain 2（匹配 /**） ... 定义一个 SecurityFilterChain @Configuration @EnableWebSecurity public class SecurityConfig { @Bean public SecurityFilterChain apiSecurityChain(HttpSecurity http) throws Exception { http .securityMatcher("/api/**") // 只匹配 /api/** 路径 .authorizeHttpRequests(auth -> auth .requestMatchers("/api/public/**").permitAll() .anyRequest().authenticated() ) .sessionManagement(session -> session .sessionCreationPolicy(SessionCreationPolicy.STATELESS) // 无状态，适合 JWT ) .csrf(csrf -> csrf.disable()); // REST API 通常关闭 CSRF return http.build(); } } HttpSecurity 是 SecurityFilterChain 的构建器，调用 .build() 后生成链实例并注册为 Bean。 ...

Lombok 是一个 Java 编译器插件，通过注解在编译期自动生成 getter/setter、构造器、equals/hashCode、toString、Builder 等样板代码，让源文件保持简洁。 发音：来自印度尼西亚龙目岛（Lombok Island），读作 LOM-bok，重音在第一个音节。 出现时间：2009 年首次发布，比 Spring Boot（2014 年）早了五年，与 Spring 没有直接关系，是独立的 Java 工具。 原理：利用 Java 编译器的注解处理器（Annotation Processing）在 javac 编译时修改语法树，将生成的方法直接写入 .class 字节码，源文件里没有这些方法但编译产物里有。IDE 需要安装 Lombok 插件才能识别生成的方法。 解决了什么问题 Java 要求显式写大量与业务无关的样板代码，一个普通的 JavaBean 需要： // 不用 Lombok：一个 User 类要写几十行 public class User { private Long id; private String name; private String email; public User() {} public User(Long id, String name, String email) { ... } public Long getId() { return id; } public void setId(Long id) { this.id = id; } public String getName() { return name; } public void setName(String name) { this.name = name; } // ... 还有 equals / hashCode / toString ... } 用 Lombok： ...

IoC（Inversion of Control，控制反转）是 Spring 的核心机制。它把"创建和管理对象"的控制权从应用代码交给 Spring 容器，应用代码只需声明依赖，容器负责提供。 IoC 的具体实现方式叫 DI（Dependency Injection，依赖注入），容器通过构造器、字段或 Setter 方法将依赖对象注入进来。 IoC 解决了什么问题 传统写法中，对象自己负责创建依赖： // 传统写法：自己创建依赖，紧耦合 public class OrderService { private UserDao userDao = new UserDaoImpl(); // 自己 new，换实现要改代码 private EmailService email = new EmailService("smtp.example.com", 465); } 这带来三个问题： 紧耦合：OrderService 直接依赖具体实现类，换实现必须修改源码 难以测试：无法替换成 Mock 对象，单元测试困难 对象生命周期散乱：每次 new 都产生新对象，无法复用单例 IoC 写法： // IoC 写法：声明需要什么，容器负责提供 @Service public class OrderService { @Autowired private UserDao userDao; // 容器注入，不关心具体实现 @Autowired private EmailService emailService; } 切换实现时只需修改容器配置，OrderService 代码本身不用动。 ...

Spring Boot 是什么 Spring Boot 是 Pivotal （现为 VMware/Broadcom）在 2014 年推出的框架，建立在 Spring Framework 之上，目标是简化整个 Spring 生态的开发、配置和部署。它不只是简化 Spring MVC，同样简化了 Spring Data（数据库访问）、Spring Security（认证授权）、Spring Messaging（消息队列）等全家桶的配置。 核心理念是 “约定优于配置”（Convention over Configuration）：框架提前定好"默认约定"，只要遵循这些约定，就不需要写任何配置；只有想偏离默认行为时，才需要显式配置。 例如，classpath 里有 spring-boot-starter-web，Spring Boot 就约定你要启动一个 Web 服务，自动完成：注册 DispatcherServlet、内嵌 Tomcat 监听 8080 端口、注册 Jackson 用于 JSON 序列化。你什么都不写，java -jar app.jar 就能跑起来。需要覆盖默认行为时，只在 src/main/resources/application.yml 中写偏离默认值的部分： server: port: 9090 # 只需声明偏离默认值的配置 也可通过命令行参数临时覆盖：java -jar app.jar --server.port=9090，优先级高于 application.yml。 出现背景 Spring Boot（2014）与微服务架构的兴起同期出现。2014 年 Martin Fowler 发表了微服务架构的奠基性文章，微服务要求每个服务独立部署、快速启动、进程隔离。传统的 WAR 包 + 外部 Tomcat 的部署方式与这一需求存在明显矛盾，Spring Boot 正是为了解决这一问题而生。 ...

SOLID 是面向对象设计的五大基本原则的首字母缩写，由 Robert C. Martin（Uncle Bob）整理归纳。这五个原则是编写可维护、可扩展代码的基础。 S — 单一职责原则 (Single Responsibility Principle, SRP) 一个类应该只有一个引起它变化的原因。 一个类只做一件事。如果一个类承担了多个职责，那么每个职责的变化都可能影响这个类，导致它越来越难以维护。 反例： 简单工厂模式中的工厂类 Driver 同时负责判断车型和创建所有车对象，违反了单一职责。 O — 开闭原则 (Open-Closed Principle, OCP) 软件实体应该对扩展开放，对修改封闭。 添加新功能时，应该通过新增代码实现，而不是修改已有代码。详见开闭原则。 反例： 简单工厂的 if/else 判断链，每新增一种产品都要修改工厂方法。 L — 里氏替换原则 (Liskov Substitution Principle, LSP) 子类必须能够替换其父类，且程序行为不变。 任何使用父类的地方，换成子类后程序应该仍然正确运行。子类不应该破坏父类的契约。 示例： Benze 和 Bmw 都实现了 Car 接口，客户端代码使用 Car 类型，无论实际是哪种车，drive() 都能正确调用。 I — 接口隔离原则 (Interface Segregation Principle, ISP) 客户端不应该被迫依赖它不使用的方法。 接口应该尽量细化，不要把不相关的方法放在同一个接口里。大接口应该拆分成多个小接口，让实现类只需要关心自己用到的方法。 反例： 一个包含 fly()、swim()、run() 的 Animal 接口，鱼类被迫实现 fly() 和 run()。 D — 依赖倒置原则 (Dependency Inversion Principle, DIP) 高层模块不应该依赖低层模块，两者都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象。 ...

开闭原则 开闭原则(Open-Close Principle/OCP)是面向对象设计中"可复用设计"的基石，是面向对象设计中最重要的原则之一，其它很多的设计原则都是实现开闭原则的一种手段。 1988年，Bertrand Meyer在他的著作《Object Oriented Software Construction》中提出了开闭原则，它的原文是这样: “Software entities should be open for extension,but closed for modification”。翻译过来就是: “软件实体应当对扩展开放，对修改关闭”。这句话说得略微有点专业，我们把它讲得更通俗一点，也就是: 软件系统中包含的各种组件，例如模块 (Modules) 、类 (Classes) 以及功能 (Functions) 等等，应该在不修改现有代码的基础上，引入新功能。开闭原则中"开"，是指对于组件功能的扩展是开放的，是允许对其进行功能扩展的；开闭原则中"闭"，是指对于原有代码的修改是封闭的，即不应该修改原有的代码。实现开闭原则的关键就在于"抽象"。把系统的所有可能的行为抽象成一个抽象底层，这个抽象底层规定出所有的具体实现必须提供的方法的特征。作为系统设计的抽象层，要预见所有可能的扩展，从而使得在任何扩展情况下，系统的抽象底层不需修改；同时，由于可以从抽象底层导出一个或多个新的具体实现，可以改变系统的行为，因此系统设计对扩展是开放的。 我们在软件开发的过程中，一直都是提倡需求导向的。这就要求我们在设计的时候，要非常清楚地了解用户需求，判断需求中包含的可能的变化，从而明确在什么情况下使用开闭原则。 关于系统可变的部分，还有一个更具体的对可变性封装原则 (Principle of Encapsulation of Variation, EVP) ，它从软件工程实现的角度对开闭原则进行了进一步的解释。EVP要求在做系统设计的时候，对系统所有可能发生变化的部分进行评估和分类，每一个可变的因素都单独进行封装。 我们在实际开发过程的设计开始阶段，就要罗列出来系统所有可能的行为，并把这些行为加入到抽象底层，根本就是不可能的，这么去做也是不经济的，费时费力。另外，在设计开始阶段，对所有的可变因素进行预计和封装也不太现实，也是很难做得到。所以，开闭原则描绘的愿景只是一种理想情况或是极端状态，现实世界中是很难被完全实现的。我们只能在某些组件，在某种程度上符合开闭原则的要求。 通过以上的分析，对于开闭原则，我们可以得出这样的结论: 虽然我们不可能做到百分之百的封闭，但是在系统设计的时候，我们还是要尽量做到这一点。 对于软件系统的功能扩展，我们可以通过继承、重载或者委托等手段实现。以接口为例，它对修改就是是封闭的，而对具体的实现是开放的，我们可以根据实际的需要提供不同的实现，所以接口是符合开闭原则的。如果一个软件系统符合开闭原则的，那么从软件工程的角度来看，它至少具有这样的好处: 可复用性好。 我们可以在软件完成以后，仍然可以对软件进行扩展，加入新的功能，非常灵活。因此，这个软件系统就可以通过不断地增加新的组件，来满足不断变化的需求。 可维护性好。 由于对于已有的软件系统的组件，特别是它的抽象底层不去修改，因此，我们不用担心软件系统中原有组件的稳定性，这就使变化中的软件系统有一定的稳定性和延续性。开闭原则具有理想主义的色彩，它是面向对象设计的终极目标。因此，针对开闭原则的实现方法，一直都有面向对象设计的大师费尽心机，研究开闭原则的实现方式。后面要提到的里氏代换原则 (LSP) 、依赖倒转原则 (DIP) 、接口隔离原则 (ISP) 以及抽象类 (Abstract Class) 、接口(Interface)等等，都可以看作是开闭原则的实现方法。 http://baike.baidu.com/view/866233.htm

设计模式 — 工厂模式, Factory 一、引子 话说十年前，有一个老板，他家有三辆汽车 —— Benz奔驰、Bmw宝马、Audi奥迪，还雇了司机为他开车。不过，老板坐车时总是怪怪的: 上Benz车后跟司机说"开奔驰车！"，坐上Bmw后他说"开宝马车！"，坐上Audi说"开奥迪车！"。你一定说: 这人有病！直接说开车不就行了？！ 而当把这个老板的行为放到我们程序设计中来时，会发现这是一个普遍存在的现象。幸运的是，这种有病的现象在 OO (面向对象) 语言中可以避免了。下面就以 Java 语言为基础来引入我们本文的主题: 工厂模式。 二、分类 工厂模式主要是为创建对象提供过渡接口，以便将创建对象的具体过程屏蔽隔离起来，达到提高灵活性的目的。 工厂模式在《Java与模式》中分为三类: 简单工厂模式 (Simple Factory) 工厂方法模式 (Factory Method) 抽象工厂模式 (Abstract Factory) 这三种模式从上到下逐步抽象，并且更具一般性。 GOF在《设计模式》一书中将工厂模式分为两类: 工厂方法模式 (Factory Method) 与抽象工厂模式 (Abstract Factory) 。将简单工厂模式 (Simple Factory) 看为工厂方法模式的一种特例，两者归为一类。 两者皆可，在本文使用《Java与模式》的分类方法。下面来看看这些工厂模式是怎么来"治病"的。 简单工厂模式, 简单工厂 (Simple Factory) 简单工厂模式又称静态工厂方法模式。从命名上就可以看出这个模式一定很简单。它存在的目的很简单: 定义一个用于创建对象的接口。 先来看看它的组成: 工厂类角色: 这是本模式的核心，含有一定的业务逻辑和判断逻辑。在 java 中它往往由一个具体类实现。 抽象产品角色: 它一般是具体产品继承的父类或者实现的接口。在 java 中由接口或者抽象类来实现。 具体产品角色: 工厂类所创建的对象就是此角色的实例。在 java 中由一个具体类实现。 来用类图来清晰的表示下的它们之间的关系 (如果对类图不太了解，请参考我关于类图的文章) : 那么简单工厂模式怎么来使用呢？我们就以简单工厂模式来改造老板坐车的方式——现在老板只需要坐在车里对司机说句: “开车"就可以了。 // 抽象产品 interface Car { void drive(); } // 具体产品 class Benze implements Car { public void drive() { System.out.println("Driving Benz"); } } // 具体产品 class Bmw implements Car { public void drive() { System.out.println("Driving Bmw"); } } // 工厂类 class Driver { // 工厂方法，注意返回类型为抽象产品 public static Car createCar(String s) throws Exception { // 判断逻辑，返回具体的产品角色给 Client if (s.equalsIgnoreCase("Benz")) { return new Benze(); } else if (s.equalsIgnoreCase("Bmw")) { return new Bmw(); } else { throw new Exception(); } } } // 客户端 public class Magnate { public static void main(String[] args) throws Exception { // 告诉司机我今天坐奔驰 Car car = Driver.createCar("benz"); // 下命令: 开车 car.drive(); car = Driver.createCar("bmw"); car.drive(); } } 将本程序空缺的其他信息填充完整后即可运行。如果你将所有的类放在一个文件中，请不要忘记只能有一个类被声明为public。本程序在jdk1.4 下运行通过。 ...

异常捕捉的确是对性能有影响的,那是因为一旦异常被抛出,函数也就跟着 return 了。而程序在执行时需要处理 函数栈 的上下文,这会导致性能变得很慢,尤其是线程栈比较深的时候。但从另一方面来说,异常的抛出基本上表明程序的错误。程序在绝大多数情况下,应该是在没有异常的情况下运行的, 所以,有异常的情况应该是少数的情况,不会影响正常处理的性能问题。 对于我们并不期望会发生的事,我们可以使用异常捕捉；对于我们觉得可能会发生的事,使用返回码。 https://time.geekbang.org/column/article/675 你觉得自己是一个Java专家吗？是否肯定自己 已经全面掌握了Java的异常处理机制？在下面这段代码中,你能够迅速找出异常处理的六个问题吗？ 1 OutputStreamWriter out = … 2 java.sql.Connection conn = … 3 try { // ⑸ 4 Statement stat = conn.createStatement(); 5 ResultSet rs = stat.executeQuery( 6 “select uid, name from user”); 7 while (rs.next()) 8 { 9 out.println(“ID: " + rs.getString(“uid”) // ⑹ 10 “,姓名: " + rs.getString(“name”)); 11 } 12 conn.close(); // ⑶ 13 out.close(); 14 } 15 catch(Exception ex) // ⑵ 16 { 17 ex.printStackTrace(); //⑴,⑷ ...

JMM, Java Memory Model, java 内存模型 Java内存模型,是指Java程序在运行时内存的模型,而Java代码是运行在Java虚拟机之上的,由Java虚拟机通过解释执行(解释器)或编译执行(即时编译器)来完成, 所以Java内存模型,也就是指Java虚拟机的运行时内存模型。 Java内存比较流行的说法便是堆和栈,这其实是非常粗略的一种划分,这种划分的"堆"对应内存模型的Java堆,“栈"是指虚拟机栈,然而Java内存模型远比这更复杂 @startuml skinparam componentStyle rectangle skinparam nodesep 10 skinparam ranksep 10 component "Java Run-time Data Areas" { [heap] component thread0 { [PC Register] as pc0 [thread stack] as ts0 [Native Method Stack] as nms0 pc0 -[hidden]-> ts0 ts0 -[hidden]-> nms0 } component thread1 { [PC Register] as pc1 [thread stack] as ts1 [Native Method Stack] as nms1 pc1 -[hidden]-> ts1 ts1 -[hidden]-> nms1 } thread0 --[hidden]--> heap thread1 --[hidden]--> heap component "method area" as ma { [constant pool] as cp } heap -[hidden]-> ma } @enduml Java 虚拟机的内存空间 (运行时数据区)分为 5 个部分: 程序计数器, PC register Java 虚拟机栈, JVM stack, 线程栈， thread stack 本地方法栈， native method stack 堆, heap 方法区, method area，方法区里面还有一个常量池 线程私有的数据区： 程序计数器，虚拟机栈，本地方法栈 所有线程共有的数据区： Java堆，方法区 ...

“Unsafe” unsafe Unsafe在sun.misc 下，顾名思义，这是一个不安全的类，因为Unsafe类所操作的并不属于Java标准，Java的一系列内存操作都是交给jvm的，而Unsafe类却能有像C语言的指针一样直接操作内存的能力，同时也会带来了指针的问题。过度使用Unsafe类的话，会使出错率变得更大，因此官方才命名为Unsafe，并且不建议使用，连注释的没有。 而为了安全使用Unsafe，Unsafe类只允许jdk自带的类使用，从下面的代码中可以看出 public static Unsafe getUnsafe() { Class<?> caller = Reflection.getCallerClass(); if (!VM.isSystemDomainLoader(caller.getClassLoader())) throw new SecurityException("Unsafe"); return theUnsafe; } 如果当前Class是非系统加载的(也就是caller.getClassLoader()不为空)，直接抛出SecurityException 。 在java9之后，又出现了一个jdk.internal.misc.Unsafe类，其功能与sun.misc.Unsafe类是一样的，唯一不一样的是在 getSafe() 的时候，jdk.internal.misc.Unsafe是没有做校验的，但是jdk包下的代码，应用开发时是不能直接调用的，而且在java9之后，两个Unsafe类都有充足的注释。 JUC紧密使用了Unsafe的功能。 功能简介 Unsafe类的功能主要分为内存操作、CAS、Class相关、对象操作、数组相关、内存屏障、系统相关、线程调度等功能。 内存操作 堆外(native memory)内存操作 //分配内存，并返回内存地址 public native long allocateMemory(long bytes); //扩充内存，address可以是allocateMemory方法返回的地址，bytes是扩充的大小 public native long reallocateMemory(long address, long bytes); //释放内存 public native void freeMemory(long address); //在给定的内存块设置默认值 public native void setMemory(long address, long bytes, byte value); //获取指定地址值的byte类型 public native byte getByte(long address); //设置堆外指定值的byte类型的值 public native void putByte(long address, byte x); ...

自动装箱 拆箱 Java作为面向对象语言，有人认为所看到的都是对象，事实上，在Java SE 5之前，基本类型默认并不是采用对象存在的如果您想要把基本类型作为对象来处理，就必须自行转换，不过，在Java SE 5之后，为基本数据类型提供了自动装箱和拆箱功能，使得将基本类型转换为对象变得极其便捷。 在这里来捋一捋java的基本数据类型，不理不要紧，一理才发现俺也掌握的不是那么明确，在这里俺也再次学习下 总计有八个，分别是 byte字节型 (一个字节) ，char字符型 (两个字节) ，short短整型 (两个字节) ，int整型 (四个字节) ， long长整型 (八个字节) ，float浮点型 (四个字节) ，double 双精度浮点型 (八个字节) ，boolean型 (一个字节) 在javase5之前，如果想要把基本数据类型作为对象来操作，就需要采用对应的对象，来把它们打包才行 现在虽然不用这样了，但其中也有一些要注意的地方，俺揪出来晒晒。 先说说类和对象，建立个概念吧先 类-可以认为是对象的设计图 对象-是按照设计图实现了的具体工具 先这么简单理解吧，如果真要扯开了说，那可是软件工程里面的一门专业课，我们有个概念就好 之所以要将基本类型数据打包成为对象，原因很简单，是因为对象可以携带更多的数据。 手动、自动装箱拆箱示例 Long，Integer，Double，Float,Boolean等等的类就是所谓的wrapper类，就跟wrapper这个单词所代表的意思一样，就是提供一个"包装，加壳"，把基本数据类型放在里面，来看代码，体会下先 public class WrapperDemo{ public staticvoid main(String[] args){ int data1=21; int data2=24; //打包成为对象 Integer data1Wrapper = new Integer(data1); Integer data2Wrapper = new Integer(data2); //原始数据直接除以3 System.out.println(data1/3); //将数据打包，转换为double型，除以3 System.out.println(data1Wrapper.doubleValue()/3); //比较 System.out.println(data1Wrapper.compareTo(data2Wrapper)); } } 图1-1 WrapperDemo的运行结果 通过上面的代码和运行结果，看到了将基本数据类型打包成为对象带来的好处了吧，别着急，这还只是javase5之前的做法，在javase5之后就已经支持自动装箱和拆箱了，在这，就不再单独写代码出来了，只写几个能说明问题的语句就可以了，相信很容易理解的。 javase5之前，手动打包 Integer data1 = new Integer(10); ...

idea plugin java 编码规范检查 Alibaba Java Coding Guidelines idea 中统计代码行数 plugin: Statistic https://blog.csdn.net/liuchaoxuan/article/details/81270341

java 模块系统, Jigsaw Java9 之前的版本 .class 文件是 JVM 看到的最小可执行文件，而一个大型程序需要编写很多 Class，并生成一堆 .class 文件，不便于管理，所以，jar 文件就是 class 文件的容器。 在 Java9 之前，一个大型 Java 程序会生成自己的 jar 文件，同时引用依赖的第三方 jar 文件，而 JVM 自带的 Java 标准库，实际上也是以 jar 文件形式存放的，这个文件叫 rt.jar，一共有 60 多 M。 如果是自己开发的程序，除了一个自己的 app.jar 以外，还需要一堆第三方的 jar 包，运行一个 Java 程序，一般来说，命令行写这样: java -cp app.jar:a.jar:b.jar:c.jar com.liaoxuefeng.sample.Main jar 只是用于存放 class 的容器，它并不关心 class 之间的依赖。 从 Java9 开始，原有的 Java 标准库已经由一个单一巨大的 rt.jar 分拆成了几十个模块，这些模块以 .jmod 扩展名标识，可以在 $JAVA_HOME/jmods 目录下找到它们: java.base.jmod java.compiler.jmod java.datatransfer.jmod java.desktop.jmod ... 这些.jmod文件每一个都是一个模块，模块名就是文件名 如果把 Java 8 比作单体应用，那么引入模块系统之后，从 Java 9 开始，Java 就华丽的转身为微服务。模块系统，项目代号 Jigsaw，最早于 2008 年 8 月提出(比 Martin Fowler 提出微服务还早 6 年)，2014 年跟随 Java 9 正式进入开发阶段，最终跟随 Java 9 发布于 2017 年 9 月。 ...

java 开发环境 jdk wiloon.com/jdk 安装 maven https://maven.apache.org/download.cgi apache-maven-3.6.3-bin.zip 安装 idea https://www.jetbrains.com/idea/download/#section=windows https://download.jetbrains.8686c.com/idea/ideaIC-2019.3.3.exe 安装 eclipse https://www.eclipse.org/downloads/packages/ Eclipse IDE for Java Developers, Windows 64-bit subclipse https://github.com/subclipse/subclipse/wiki Help>Install New Software>Add latest: https://dl.bintray.com/subclipse/releases/subclipse/latest/

netty Reactor模式 Reactor模式的角色构成(Reactor模式一共有5中角色构成)： Handle (句柄或描述符，在Windows下称为句柄，在Linux下称为描述符)：本质上表示一种资源(比如说文件描述符，或是针对网络编程中的socket描述符)，是由操作系统提供的；该资源用于表示一个个的事件，事件既可以来自于外部，也可以来自于内部；外部事件比如说客户端的连接请求，客户端发送过来的数据等；内部事件比如说操作系统产生的定时事件等。它本质上就是一个文件描述符，Handle是事件产生的发源地。 Synchronous Event Demultiplexer (同步事件分离器)：它本身是一个系统调用，用于等待事件的发生(事件可能是一个，也可能是多个)。调用方在调用它的时候会被阻塞，一直阻塞到同步事件分离器上有事件产生为止。对于Linux来说，同步事件分离器指的就是常用的I/O多路复用机制，比如说select、poll、epoll等。在Java NIO领域中，同步事件分离器对应的组件就是Selector；对应的阻塞方法就是select方法。 Event Handler (事件处理器)：本身由多个回调方法构成，这些回调方法构成了与应用相关的对于某个事件的反馈机制。在Java NIO领域中并没有提供事件处理器机制让我们调用或去进行回调，是由我们自己编写代码完成的。Netty相比于Java NIO来说，在事件处理器这个角色上进行了一个升级，它为我们开发者提供了大量的回调方法，供我们在特定事件产生时实现相应的回调方法进行业务逻辑的处理，即，ChannelHandler。ChannelHandler中的方法对应的都是一个个事件的回调。 Concrete Event Handler (具体事件处理器)：是事件处理器的实现。它本身实现了事件处理器所提供的各种回调方法，从而实现了特定于业务的逻辑。它本质上就是我们所编写的一个个的处理器实现。 Initiation Dispatcher (初始分发器)：实际上就是Reactor角色。它本身定义了一些规范，这些规范用于控制事件的调度方式，同时又提供了应用进行事件处理器的注册、删除等设施。它本身是整个事件处理器的核心所在，Initiation Dispatcher会通过 Synchronous Event Demultiplexer 来等待事件的发生。一旦事件发生，Initiation Dispatcher 首先会分离出每一个事件，然后调用事件处理器，最后调用相关的回调方法来处理这些事件。Netty中ChannelHandler 里的一个个回调方法都是由 bossGroup 或 workGroup 中的某个EventLoop来调用的。 Reactor模式流程 ① 初始化Initiation Dispatcher，然后将若干个Concrete Event Handler注册到Initiation Dispatcher中。当应用向Initiation Dispatcher注册Concrete Event Handler时，会在注册的同时指定感兴趣的事件，即，应用会标识出该事件处理器希望Initiation Dispatcher在某些事件发生时向其发出通知，事件通过Handle来标识，而Concrete Event Handler又持有该Handle。这样，事件 ————> Handle ————> Concrete Event Handler 就关联起来了。 ② Initiation Dispatcher 会要求每个事件处理器向其传递内部的Handle。该Handle向操作系统标识了事件处理器。 ③ 当所有的Concrete Event Handler都注册完毕后，应用会调用handle_events方法来启动Initiation Dispatcher的事件循环。这是，Initiation Dispatcher会将每个注册的Concrete Event Handler的Handle合并起来，并使用Synchronous Event Demultiplexer(同步事件分离器)同步阻塞的等待事件的发生。比如说，TCP协议层会使用select同步事件分离器操作来等待客户端发送的数据到达连接的socket handler上。 比如，在Java中通过Selector的select()方法来实现这个同步阻塞等待事件发生的操作。在Linux操作系统下，select()的实现中 a)会将已经注册到Initiation Dispatcher的事件调用epollCtl(epfd, opcode, fd, events)注册到linux系统中，这里fd表示Handle，events表示我们所感兴趣的Handle的事件；b)通过调用epollWait方法同步阻塞的等待已经注册的事件的发生。不同事件源上的事件可能同时发生，一旦有事件被触发了，epollWait方法就会返回；c)最后通过发生的事件找到相关联的SelectorKeyImpl对象，并设置其发生的事件为就绪状态，然后将SelectorKeyImpl放入selectedSet中。这样一来我们就可以通过Selector.selectedKeys()方法得到事件就绪的SelectorKeyImpl集合了。 ④ 当与某个事件源对应的Handle变为ready状态时(比如说，TCP socket变为等待读状态时)，Synchronous Event Demultiplexer就会通知Initiation Dispatcher。 ⑤ Initiation Dispatcher会触发事件处理器的回调方法，从而响应这个处于ready状态的Handle。当事件发生时，Initiation Dispatcher会将被事件源激活的Handle作为『key』来寻找并分发恰当的事件处理器回调方法。 ⑥ Initiation Dispatcher会回调事件处理器的handle_event(type)回调方法来执行特定于应用的功能(开发者自己所编写的功能)，从而相应这个事件。所发生的事件类型可以作为该方法参数并被该方法内部使用来执行额外的特定于服务的分离与分发。 ...

Java诊断工具 - btrace https://github.com/btraceio/btrace/releases 打印慢调用 创建一个java类 // MethodDuration_redis.java import com.sun.btrace.annotations.*; import static com.sun.btrace.BTraceUtils.*; import java.util.Date; @BTrace public class MethodDuration_redis{ private static int i=0; @OnMethod(clazz = "com.wiloon.package0.Class0",method = "method0",location=@Location(Kind.RETURN)) public static void printMethodRunTime(@ProbeClassName String probeClassName,@Duration long duration){ long d=duration / 1000000; if (d>9){ //大于9毫秒的调用 i++; println("index: "+ i +", timestamp:"+timestamp("HH:mm:ss")+", "+probeClassName + ", duration: " + d + " ms"); } } } 找到 java 进程并执行 btrace # 打印java进程 jcmd -l # 执行btrace, ctrl-c 退出 /bin/btrace <PID> MethodDuration_redis.java Btrace BTrace 是检查和解决线上的问题的杀器，BTrace 可以通过编写脚本的方式，获取程序执行过程中的一切信息，并且，注意了，不用重启服务，是的，不用重启服务。写好脚本，直接用命令执行即可，不用动原程序的代码。 ...

netty ByteBuf Netty ByteBuf 优势 Netty 提供了ByteBuf，来替代Java NIO的 ByteBuffer，操作内存缓冲区。 与Java NIO的 ByteBuffer 相比，ByteBuf的优势如下： Pooling (池化，这点减少了内存复制和GC，提升效率) 可以自定义缓冲类型 通过一个内置的复合缓冲类型实现零拷贝 扩展性好，比如 StringBuffer 不需要调用 flip()来切换读/写模式 读取和写入索引分开 方法链 引用计数 ———————————————— 版权声明：本文为CSDN博主「架构师-尼恩」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/crazymakercircle/article/details/84198042 https://caorong.github.io/2017/01/16/head-first-netty-3/ https://segmentfault.com/a/1190000007560884 根据 Wiki 对 Zero-copy 的定义: “Zero-copy” describes computer operations in which the CPU does not perform the task of copying data from one memory area to another. This is frequently used to save CPU cycles and memory bandwidth when transmitting a file over a network. ...

jetty-maven-plugin, jetty maven plugin maven plugin <plugin> <groupId>org.eclipse.jetty</groupId> <artifactId>jetty-maven-plugin</artifactId> <version>9.4.33.v20201020</version> <configuration> <stopKey>stop</stopKey> <stopPort>5599</stopPort> <webApp> <!-- <contextPath>/app0</contextPath> --> <contextPath>/</contextPath> <defaultsDescriptor>src/main/resources/webdefault.xml</defaultsDescriptor> </webApp> <scanIntervalSeconds>2</scanIntervalSeconds> [httpConnector](httpConnector) <port>8080</port> </httpConnector> </configuration> </plugin> webdefault.xml 可以去maven的本地仓库找到 .m2\repository\org\eclipse\jetty\jetty-webapp\9.4.20.v20190813 解压后在这里可以找到webdefault.xml jetty-webapp-9.4.20.v20190813\org\eclipse\jetty\webapp run mvn jetty:run mvnDebug jetty:run # 默认调试端口8000 debug - mvnDebug https://blog.wiloon.com/?p=15212 mvnDebug -suspend默认为n, https://www.eclipse.org/jetty/documentation/jetty-11/programming-guide/index.html#jetty-maven-plugin http://www.blogjava.net/fancydeepin/archive/2015/06/23/maven-jetty-plugin.html https://my.oschina.net/jackieyeah/blog/524556 https://stackoverflow.com/questions/7875002/setting-debug-configuration-for-mavenjettyeclipse

ConcurrentLinkedQueue http://www.infoq.com/cn/articles/ConcurrentLinkedQueue 一个基于链接节点的无界线程安全队列。此队列按照 FIFO（先进先出）原则对元素进行排序。队列的头部 是队列中时间最长的元素。队列的尾部 是队列中时间最短的元素。 新的元素插入到队列的尾部，队列获取操作从队列头部获得元素。当多个线程共享访问一个公共 collection 时，ConcurrentLinkedQueue 是一个恰当的选择。此队列不允许使用 null 元素。 https://www.cnblogs.com/yangzhenlong/p/8359875.html ConcurrentLinkedQueue是Queue的一个安全实现．Queue中元素按FIFO原则进行排序．采用CAS操作，来保证元素的一致性。 https://blog.51cto.com/u_15259710/3193985 https://juejin.cn/post/6844903602427805704