概述

虚拟线程（Virtual Thread）是一种用户态轻量级线程，它在Project Loom中孵化了很久，最早以预览特性的形式出现在Java 19中。它的实现基于协程（Coroutine）的概念，而协程是一种轻量级的线程模型，在一个传统的Java线程内可以运行多个虚拟线程，每个虚拟线程都有自己的执行上下文。虚拟线程的引入旨在解决传统线程的一些问题，比如：线程创建和上下文切换的成本过高等。

创建型模式概述

创建型模式是处理对象创建的设计模式，试图根据实际情况使用合适的方式创建对象，因为基本的对象创建方式可能会导致设计上的问题，或增加设计的复杂度。创建型模式的关注点是如何创建对象，其核心思想是要把对象的创建和使用相分离。

创建型模式旨在将系统与它的对象创建、结合、表示的方式分离。这些设计模式在对象创建的类型、主体、方式、时间等方面提高了系统的灵活性。

创建型模式由两个主导思想构成：一是将系统使用的具体类封装起来，二是隐藏这些具体类的实例创建的方式。创建型模式又分为对象创建型模式和类创建型模式。对象创建型模式处理对象的创建，类创建型模式处理类的创建。详细地说，对象创建型模式把对象创建的一部分推迟到另一个对象中，而类创建型模式将它对象的创建推迟到子类中。

设计模式概述

• 设计模式（Design Pattern）是针对软件设计中普遍存在（反复出现）的各种问题所提出的解决方案；
• 该术语由Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides等人在1990年代从建筑设计领域引入到计算机科学，而该4人被称为Gang of Four（简称GoF）。
  阅读全文 »

GroovyHelp简介

  GroovyHelp是一款针对Javadoc及Groovydoc研发的多功能API文档管理软件，它能够帮助Java开发人员、Groovy开发人员以及Android开发人员方便快速地搜索、查阅、比较API文档并对其进行高效管理，从此无需苦苦寻觅chm格式的帮助文档了。可访问GroovyHelp项目首页，获悉GroovyHelp最新信息。

概述

invokedynamic是直到Java 7才引入的bytecode指令，当初设计该指令时，是为了方便JVM动态语言的实现，比如Groovy、JRuby、Jython等，而其真正被Java界关注到则是从Java 8开始，因为Java 8引入了Lambda Expression以及Method Reference这两大特性，其实现便是基于invokedynamic指令完成的。

概述

分布式事务可以简单地分解为两部分：“分布式”与“事务”，即一种分布式系统中横跨多个服务的事务。相比传统的数据库本地事务，分布式事务受限于CAP定理，往往是一种“阉割”版的事务，因而难以满足传统事务4大特性ACID(Atomicity, Consistency, Isolation, Durability)的全部要求。 而处理分布式事务的处理方案多种多样，也各有利弊，下面将对常见几种方案进行逐一阐述。

概述

为了进一步兼容Java，我们Groovy核心团队决定从Groovy 4.0.0开始支持Switch Expression、Record Class、Sealed Class等Java语言特性。值得注意的是，即使Groovy 4.0.0运行在Java 8上，这些新特性依然可以使用。除了兼容Java语言特性外，Groovy自身也新增了不少实用的新特性，比如增强Range、支持TOML、Java化（@POJO）、GINQ（Groovy-Integrated Query）等。

背景介绍

C#最先引入LINQ特性，其强大的功能令我垂涎已久，并琢磨着为Groovy也添加类似特性，终于在Groovy 4中决定完成这一夙愿。GINQ是Groovy-Integrated Query的缩写，意在对集合的操作以类SQL的方式完成，将来或许会扩展至对数据库的支持。另外，结合Groovy的XML, JSON, YAML等文本解析特性，GINQ可天然地支持对这些文本内容进行查询。

概况

Groovy最初于2003年由James Strachan设计并实现了其原型，迄今已十八岁。Groovy的成长过程，也是众多智者贡献心力的过程。而我大约在2006年底开始研究Groovy，那时Groovy 1.0正式版还没发布，主要由Jochen Theodorou一人维护，所以Jochen Theodorou在我心里一直是Groovy的养父。当初如果没有他的坚持，Groovy很可能早已夭折。而在Groovy 1.0正式版本发布后，Groovy的贡献者逐渐增多，其中令我印象比较深刻的贡献者有以下这么几位：

  虽然Groovy 3 Alpha版本就已经支持Java 8的Lambda、Method Reference以及Constructor Reference全部语法，但从bytecode层面来看，其本质上依然是Closure及Method Pointer，换言之，只是语法上的兼容，但性能上并没有提升。而Groovy的性能常为人诟病，所以Groovy 2引入了静态编译，其编译出来的bytecode跟Java的相近，所以其性能逼近Java。为了延续静态编译的性能优势，Groovy核心团队决定在Groovy 3 Beta版本中实现Lambda、Method Reference以及Constructor Reference的Native版本，其语法不变，但生成的bytecode与Java的相似，这便是”Native”的由来。