Java 代码中如果显式的用throw关键字抛出异常，那么在该分支中其后的语句不可到达，并且即使对于有返回值的函数也不必写return语句了。像下面的代码1private static int foo(int num) { 2 if (num == 0) { 3 throw new RuntimeException(""); 4 } else { 5 return num + 1; 6 } 7}
以上代码是合法的。要清洁代码的话，最后的return num + 1不必写在else条件中，这样写只是为了验证抛出异常后不必有返回值。
比如我们想对该代码进行重构，把throw语句抽取到一个方法中，以便于在该方法中集中处理错误信息，于是变成了 Read More
不得不承认因为 ChatGPT 为代表的 AI 的出现，让许多技术博客的写作者积极性大大降低。但本着以学习掌握知识为目的，实战，写下来对加强学习仍然是非常有意义的。如果一直使用 AI 来解决技术问题，知识永远是 AI 的，至于说有了 AI 本应没有主动学习必要的性的话，永远保持像一张白纸，A4 大小，那真就无话可说了。
开发过程驱动有分 TDD(Test-Driven Development) 和 BDD(Behavior-Driven Development)，大致的理解是 TDD 更关注实现细节，BDD 更接近于 QA 的测试，对领域的测试。BDD 从抽象中来讲更适于做面向用户的集成测试。当然在 AI 生成代码的年代可能单玩测试反而不那么重要，因为更多是一次性代码。
BDD 给人最典型的印象是 Scenario/Given/When/Then, BDD 最流行的测试框架当属 Cucumber, 它以插件的方式支持众多编程语方，如官方支持的用 JavaScript, Java, Kotlin, Ruby, Lua, Scala, C++, Go, OCaml, 还有其他半官支持的 Python, Swift/ObjC, Perl, .NET(C#, F#, VB), 以及非官方支持的 Rust, D, Groovy 等。
另外还有一个专供 Java 的轻量级 JBehave, 不过个人更推荐用 Cucumber, 因为 Cucumber 得到更多 IDE 如 IntelliJ, Eclipse, VS Code 等的支持，并能与 JUnit 4, JUnit 5, TestNG, 以及 Spring Boot 项目集成，内置的测试报告插件，多语言当然是个亮点。
本文主要关注 Maven 项目中如何使用 Cucumber, 循序渐进的从简单的测试开始，然后跃进到与 JUnit 5/ JUnit 4 的结合，以及普通 Unit Test 和 BDD 测试如何并存且可区分的执行，或者在 Maven 中创建独立的 src/bdd 目录单独存放 BDD 测试用例。 Read More
回看三年前的一篇日志 Mockito 3.4.0 开始可 Mock 静态方法，最后对 Mockito 产生的缺憾是它无法用来 Mock 非测试线程(主线程)中的静态方法调用。其实这也是可以变通的，下面慢慢道来。
首先回顾一下 Mockito 的静态方法 Mock 的使用方法，随着 Mockito 版本的升级，引入依赖的方式也发生了些许的变化，以 Maven 项目为例，如果在 JUnit 5 下用 Mockito 的 pom.xml 依赖中为1<dependency> 2 <groupId>org.mockito</groupId> 3 <artifactId>mockito-junit-jupiter</artifactId> 4 <version>5.14.1</version> 5 <scope>test</scope> 6</dependency>
由它引入的全部相关依赖
Read More- ThreadLocal 是 Java 编程人员要掌握的一个基本类，似乎没什么太多要说。但因为本文要牵出 TransmittableThreadlLocal, 再顺带说下几乎隐形的 InheritableThreadLocal。
ThreadLocal 用于保存与线程绑定的数据，它在框架内部使用的很频繁，但凡见到 XxxContextHolder.currentContext() 之类的十之八九用到了 ThreadLocal, 如 Spring 框架中的
RequestContextHolder1public abstract class RequestContextHolder { 2 private static final ThreadLocal<RequestAttributes> requestAttributesHolder = new NamedThreadLocal("Request attributes"); 3 private static final ThreadLocal<RequestAttributes> inheritableRequestAttributesHolder = new NamedInheritableThreadLocal("Request context");
Read More 
看国内的一些项目时 Dubbo 这个词经常闪现，一直也不以为然，未作搜索，当然也不知道它是做什么用的。直到最近阅读关于大型网站架构相关的书中反复提到 Dubbo 后，觉得不能再对它视而不见。Google 了一下，它是在阿里巴巴创建贡献给了 Apache 的开源项目，在阿里巴巴的大型应用中久经考验过的。Dubbo 是什么呢？借用官方 Dubbo 介绍Apache Dubbo 是一款 RPC 服务开发框架，用于解决微服务架构下的服务治理与通信问题，官方提供了 Java、Golang 等多语言 SDK 实现。使用 Dubbo 开发的微服务原生具备相互之间的远程地址发现与通信能力， 利用 Dubbo 提供的丰富服务治理特性，可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。Dubbo 被设计为高度可扩展，用户可以方便的实现流量拦截、选址的各种定制逻辑。
Dubbo 是国内企业贡献的，所以官方有原生的中文文档，它某些时候与 Spring Cloud 齐名，又有些像 AWS 的 ECS Service Discovery, Service Connect 加上 ELB 的功能。 Read More- 我们通常用的 Java 缓存基本可认为是扩展了 HashMap 或 ConcurrentHashMap 的实现，它们各自实现自己的缓存策略，如时间与空间的控制，生命周期管理，是否支持分布式，溢出时能否转储到磁盘。关于 Java 本地缓存的存储分为内存与磁盘，内存多数情况下指的是堆内内存(on-heap), 而介于堆内内存与文件存储之间的就是堆外内存(off-heap)
- 堆内存储(on-heap): 操作最快，无需序列化，但大量数据时会影响到 GC 的效率
- 堆外存储(off-heap): 存储在 Java 进程内存但非 JVM 堆内(不在 -Xmx 指定的内存范围内)，使用或保存时需进行序列化/反序列化过程(在堆内与堆外转换)，但不受 GC 影响，有助于提它来 GC 的效率
- 文件存储：不仅存在序列化与反序列化过程，还带 IO 操作，所以最慢，唯一优点就是大
我们查看一下当前 Spring 支持的缓存实现, Supported Cache Providers, 列有 Generic, JCache(JSR-107), EhCache 2.x, Hazelcast, Infinispan, Couchbase, Redis, Caffeine, Simple， 这其中无一支持堆外缓存，其中的 EhCache 要付费使用 EhCache 3(Big Memory) 才能支持 off-heap。 Read More - 我们在创建 Java 线程池，无论是用 Executors, ThreadPoolExecutor, 还是 Spring 的 ThreadPoolTaskExecutor, 如果不指定工作队列的大小的话，默认为 Integer.MAX_VALUE(2147483647), 基本不会把它爆满，但是在许多的任务要执行时大量 Runnable 对象的创建却足以把内存撑爆掉。所以才有必要使用一个有限大小的工作队列，如 5000, 再配上 RejectedExecutionHandler(DiscardOldestPolicy, DiscardPolicy, 或 CallerRunsPolicy)。前两种策略会主动放弃最旧最新的任务，一般不是我们想要的，CallerRunsPolicy 还能主动发挥任务提交者的计算能力，是一种不错的选择(只可能会发生工作队列太小且提交者执行的任务太忙时产生线程池一时的空闲。
所以总结起来我们可以有以下几种实现直接使用 CallerRunsPolicy
在工作队列满时有效利用提交任务的线程，不让它闲着，这种实现最简单, 像下面那样声明线程池Read More1var threadPool = new ThreadPoolExecutor(2, 5, 0L, TimeUnit.SECONDS, new LinkedBlockingQueue<>(10), 2 new ThreadPoolExecutor.CallerRunsPolicy()); - 使用 Java 处理 Object 与 XML 之间的转换时 JAXB(Java Architecture for XML Binding) 仍然被广泛使用。但随着 Java 9 模块化后把 JAXB 从标准 JDK 中移除后，和 Java EE 8(Jakarta EE 8) 到 Jakarta EE 9 的变迁时命名空间由
javax.*变成了jakarta.*，我们在使用 JAXB 时需作出相应的适配。
本文分别使用 Java 1.8, 17，通过 Maven 插件 jaxb2-maven-plugin 的 xjc (从 xsd 文件生成 Java 类), 和如何切换jakarta.*命名空间，由此可给我们对使用了 JAXB 的项目升级 JDK 时指明方向。从而不致于因不了解每部分组件的具体功效而在 pom.xml 中胡乱配置，比如之前对 jaxb2-maven-plugin 插件本身配置了多余的 org.glassfish.jaxb:jaxb-xjc 和 org.glassfish.jaxb:jaxb-runtime 依赖，也未能理解 jaxb2-maven-plugin 与 org.glassfish.jaxb:jaxb-runtime 之间的版本对应关系。
实验准备，创建简单的 Maven 项目，并在路径 src/main/xsd/ 下新建 Schema 文件 sample.xsd，内容为 Read More - 本篇同样是阅读《100 Java Mistakes and How to Avoid Them》的一则笔记，只是火力全集中在 StackOverflowError 这个单一主题之上, 且主要与递归及尾递归优化相关。一提到 StackOverflow, 恐怕首先是想到那个代码搬运源网站 stackoverflow.com，其次才是代码执行过程中的 StackOverflowError 错误。
什么是 StackOverflow, 准确来说是指线程的栈内存不足，无法在栈中分配新的内存(或创建新的栈帧)。我们通常会把它与方法调用关联起来，因为一次方法调用会创建一个新的栈帧，分配在栈上的局部变量(包括基本类型与对象引用)，和栈帧都要占用线程栈内存。而我们平时所说的方法调用栈，或出现异常时打印出的异常栈都是一个概念。
StackOverflowError 一般出现在方法调用太深(方法调方法)，手动编写的方法调用一般不容易达到这个限制，所以它与递归调用关系最为密切，递归调用次数太多或甚至没有出口条件无限递归; 也可能是经过一番递归调用后，再正常调用后续方法时出现 StackOverflowError(因为前面的递归调用资源消耗的差不多)
何谓递归调用，简单的说就是方法自己调用自己，从而实现循环的效果，或使代码更精练，例如经典排序中的快速和归并排序就要用到递归。但循环与递归又有本质上的区别，循环不增加调用深度；递归却不同，递归分递进与回归两个过程，递进调用时每次调用前都需通过压栈来保留现场，逆向回归时再逐级恢复现场，保留现场的过程就要从线程栈中分配内存空间; 死循环可能不会造成程序异常，但死(无限)递归必定出现 StackOverflowError。 Read More
