Forem: [yun]

Java 25：值得关注的新特性

[yun] — Sat, 04 Oct 2025 08:08:30 +0000

上一篇我们聊了《JDK 8 -> 20 最重用的新增特性》，
这次我们就来看看跨到Java 25有的现代化蜕变。

Java 每 6 个月一个版本，但并不是每次更新都值得你停下手里的项目去研究。
这篇文章帮你抓重点：
从 Java 20 → Java 25，哪些特性是真正「能提升生产力」的？
哪些语法变化会让你少写几行代码？
哪些性能优化会让你的服务启动更快？

📆 最新 LTS：Java 25（2025 年 9 月发布）
🌍 官方项目页：https://openjdk.org/projects/jdk/25/

🎯 为什么 Java 25 值得关注

Java 25 是继 Java 21 之后的新 LTS 版本。
这意味着：

你可以放心升级、长期支持、放上生产没问题。

从 Java 20 开始，平台的演进方向很清晰：

🧩 简化语法（Pattern Matching, Records, 简化 main）
🧵 并发模型现代化（Loom, Scoped Values, Structured Concurrency）
⚙️ 性能内核再优化（AOT, GC, JIT 混合）
🔍 可观察性增强（JFR, Profiling）
🔐 安全 API 补齐（KDF, PEM 支持）

Java 25 正是把这些「预览特性」打磨成稳定、实用的版本。
所以，这次不是“多几个语法糖”那么简单，而是一次全面成熟化。

📊 一图看完 Java 25 的主要更新

模块	特性	状态	实际意义
语言	🧠 原始类型模式匹配 (JEP 507)	第三预览	`switch` / `instanceof` 支持 `int`, `double` 等
语言	📦 模块导入声明 (JEP 511)	预览	终于能 `import module`
语言	✨ Compact Source Files / Instance Main (JEP 512)	正式	Java 也能像脚本一样写
并发	🧵 Structured Concurrency (JEP 505)	第五预览	虚拟线程的理想搭档
并发	🧭 Scoped Values (JEP 506)	正式	安全替代 `ThreadLocal`
性能	🚀 AOT + Method Profiling (JEP 514 / 515)	正式	JVM 冷启动快 30–70%
GC	🧹 Compact Object Headers (JEP 519)	正式	对象头更小，省内存
GC	🌱 Generational Shenandoah (JEP 521)	正式	更稳定的低延迟 GC
监控	🔬 JFR Method Timing (JEP 520)	正式	性能分析更精细
加密	🔐 Key Derivation API (JEP 510)	正式	原生支持 PBKDF2 / HKDF
加密	🗝️ PEM Encodings (JEP 470)	预览	内置 PEM 格式支持
平台	💀 移除 32-bit x86	移除	正式告别 32 位时代

🚀 真正有感觉的 6 大实用更新

1️⃣ 冷启动提速：AOT + Method Profiling (JEP 514 / 515)

JVM 启动性能终于不再是短板。
现代应用越来越依赖微服务、云原生部署、容器环境，冷启动 / 弹性伸缩时的启动延迟是痛点。

Java 25 做了两件事来治这病：

JEP 515 – 方法剖析 (Method Profiling)
JVM 可以在启动时直接用历史 Profile 信息预热 JIT 编译。
换句话说，它一上来就知道“哪些方法是热点”，少走弯路。
JEP 514 – AOT 命令行增强
简化了 AOT 缓存生成命令，让开发者更容易用上启动优化。

💡 建议：

若是 Serverless / 短生命周期应用，强烈建议试试。
生产前先做 A/B 测试，有些 Profile 不匹配会反降性能。
加入启动日志对比：-XX:+PrintCompilation / JFR 记录。
profile 数据要定期更新，否则会“学坏”。

# 先生成 profile 数据
java -XX:+RecordProfilingData -jar MyService.jar

# 再次启动时使用
java -XX:UseProfilingDataFile=profile.jfr -jar MyService.jar

2️⃣ 更轻的对象：Compact Object Headers (JEP 519)

对象头从 128 bits → 64 bits，平均内存节省 5–15%。

一句话：对象更小、内存更省。

💡 提示：

现在是正式功能，不再需要 UnlockExperimentalVMOptions。
可通过 -XX:+UseCompactObjectHeaders 开启。
兼容性要测：有些 JNI 或 Unsafe 代码可能依赖旧布局。

3️⃣ 新的线程上下文：Scoped Values (JEP 506)

ThreadLocal 终于有安全、轻量的替代方案。

🔧 Before（传统写法）

private static final ThreadLocal<UserContext> context = new ThreadLocal<>();

void process() {
    context.set(new UserContext("andy"));
    handleRequest();
    context.remove();
}

问题：

忘记 remove() 容易内存泄漏。
在虚拟线程（Loom）中成本高。

⚡️ After（Java 25 Scoped Values）

static final ScopedValue<UserContext> context = ScopedValue.newInstance();

void process() {
    ScopedValue.runWhere(context, new UserContext("andy"), () -> {
        handleRequest();
    });
}

✅ 自动作用域控制
✅ 无需清理
✅ 完全兼容虚拟线程

💡 建议：
用在 request context、trace id、tenant info 等「临时上下文数据」非常香。

4️⃣ Pattern Matching for Primitive Types (JEP 507)

终于可以在 switch 中匹配 int, double 等原始类型。

🔧 Before（传统写法）

Object o = 42;
if (o instanceof Integer i) {
    System.out.println(i * 2);
} else if (o instanceof Double d) {
    System.out.println(d / 2);
}

⚡️ After

Object o = 42;
switch (o) {
    case int i -> System.out.println(i * 2);
    case double d -> System.out.println(d / 2);
    default -> System.out.println("other");
}

更自然、更一致。
仍属预览特性（需 --enable-preview）。

5️⃣ 更轻的脚本体验：Compact Source Files (JEP 512)

“写个 Hello World 还得套个类？”
Java 25 终于说：不用了。

🔧 Before

public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello, Java!");
    }
}

⚡️ After

void main() {
    println("Hello, Java 25!");
}

✅ 无需类声明
✅ 自带 println / readln
✅ 默认导入常用包（java.util, java.io 等）

非常适合脚本、小工具、教学 demo。

6️⃣ 安全 API 补齐：KDF + PEM 支持 (JEP 510 / 470)

再也不用 BouncyCastle 了。

🔧 Before

SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
// 依赖第三方或手动写 PEM 解析

⚡️ After

var kdf = KeyDerivationFunction.getInstance("HKDF");
var derived = kdf.deriveKey(secret, "context-info");

var pem = PemEncoded.read(new File("key.pem"));

✅ 原生支持 PBKDF2、HKDF
✅ 官方 PEM 解析（再也不用 Apache Commons SSL）
✅ 更安全、更兼容 FIPS

🧭 升级建议（20/21 → 25）

步骤	建议动作	说明
1️⃣	先在测试环境切 JDK 25	检查依赖兼容
2️⃣	对性能敏感模块基准测试	验证 GC / 启动速度
3️⃣	尝试 `--enable-preview`	提前熟悉 Pattern Matching
4️⃣	启用 Compact Headers	检查内存节省比例
5️⃣	集成 JFR 新功能	改进性能监控体系
6️⃣	评估 AOT + Profile 启动	Serverless 项目推荐
7️⃣	移除 32 位依赖	避免启动错误

💬 总结：要不要上 Java 25？

场景	建议
🚀 新项目	直接上 Java 25
🏢 Java 21 LTS 生产项目	准备迁移
🧓 Java 17 / 8 老项目	是时候动手了 😅

🧠 TL;DR — 最推荐的 5 个特性

排名	特性	用途
🥇	AOT + Method Profiling	冷启动提速
🥈	Compact Object Headers	节省内存
🥉	Scoped Values	并发安全上下文
#4	JFR Profiling	精准监控
#5	Compact Source Files	轻量脚本体验

👉 你升级 Java 25 了吗？
冷启动真的快了吗？你最喜欢哪个新特性呢？
欢迎在评论区聊聊你的实测体验 🙌

从“能用”到“好用”：高效运用CloudBees CD/RO 的使用心得

[yun] — Sun, 22 Jun 2025 17:07:33 +0000

在软件交付的世界里，CI/CD 流水线已经不是什么新鲜事。我们用 Jenkins、GitLab CI 或其他工具构建、测试、打包我们的应用。但当交付的规模和复杂度上升时，尤其是在需要协调多个应用、跨多个环境、并涉及严格发布流程的企业场景下，简单的 CI 流水线就显得力不存心了。

这就是 CloudBees CD/RO (Continuous Delivery / Release Orchestration) 发挥作用的地方。它不仅仅是一个执行脚本的工具，更是一个强大的平台，用于建模、管理和可视化你的整个软件交付流程。

然而，很多团队仅仅是用它来替代旧的部署脚本，没有真正发挥其潜力。今天，我想分享一些心得，帮助你从“能用” CloudBees CD/RO，迈向“好用”和“高效”。

1. 核心概念：像写代码一样思考你的部署

CloudBees CD/RO 的核心是其强大的对象模型。要高效使用它，首先必须理解并接受这个模型。把它想象成部署世界的“面向对象编程”：

Application (应用): 这是你要部署的东西。它不是代码库，而是包含了部署逻辑（Components）和流程（Processes）的集合。一个应用可以包含一个后端服务、一个前端UI和一个数据库脚本。
Environment (环境): 这是你要部署到的地方（如 DEV, QA, PROD）。它不关心“如何部署”，只关心“部署到哪”，并存储该环境特定的配置，如服务器地址、数据库凭证等。
Process (流程): 这是“如何做”的定义。例如，一个 Deploy 流程可能包含“从 Artifactory 拉取构件”、“停止应用服务器”、“部署文件”、“启动应用服务器”等步骤。

高效实践的关键在于：将部署逻辑（Process）与环境配置（Environment）彻底分离。你的部署流程应该是一套代码，无需任何修改就能在所有环境中运行。

2. “一切皆代码”：全面拥抱 DSL

如果你还在 UI 上拖拖拽拽来创建流程，请立刻停下来。CloudBees CD/RO 提供了强大的 Groovy/Kotlin DSL（领域特定语言），让你能够以代码的形式定义所有配置。

为什么必须用 DSL？

版本控制: 你可以将你的整个发布流程和应用模型存储在 Git 中，享受版本控制、分支、合并带来的所有好处。
代码审查: 对发布流程的任何修改都必须通过 Pull Request 和同行评审，极大地提高了变更的可靠性。
可复用性: 你可以编写通用的 DSL 模块，并在多个项目中共享。
自动化: 可以通过脚本自动创建和更新成百上千个应用，这在微服务架构中至关重要。

示例：用 DSL 定义一个简单的应用

// file: project/applications/my-web-app.groovy

application 'my-web-app', {
    projectName = 'My Awesome Project'
    description = 'Main web application'

    // 定义一个组件，指向构件仓库
    component 'war-file', {
        artifactName = 'my-app'
        artifactVersion = '$[pipeline.buildNumber]' // 使用运行时参数
        retrievalMode = 'artifact'
        artifactType = 'REPOSITORY'
        repositoryName = 'artifactory-prod' // 指向配置好的仓库
    }

    // 定义一个部署流程
    process 'deploy', {
        formalParameter 'target_server', required: true, type: 'entry'

        step 'retrieve_artifact', {
            command = null
            subprocedure = 'retrieve'
            subprocedureType = 'component'
            actualParameter 'componentName', 'war-file'
            actualParameter 'target', '/tmp'
        }

        step 'deploy_to_tomcat', {
            command = "scp /tmp/my-app-$[artifactVersion].war $[/myJob/target_server]:/opt/tomcat/webapps/"
            shell = 'bash'
        }
    }
}

通过 evalDsl 命令，你就可以将这段代码应用到你的 CloudBees CD/RO 服务器上。

3. 可重用性是关键：构建模块化的流程

不要在应用流程（Application Process）中编写具体的执行逻辑。相反，你应该创建通用的程序（Procedures），然后在应用流程中调用它们。

反模式 ❌:

在 my-web-app 的 deploy 流程中硬编码所有 Tomcat 部署细节。

最佳实践 ✅:

创建一个名为 Tomcat/Deploy 的通用 Procedure。
这个 Procedure 接受参数，如 warFilePath, targetServer, tomcatManagerUser。
在 my-web-app 的 deploy 流程中，简单地调用这个通用 Procedure，并传入参数。

这样做的好处是显而易见的。当你需要部署另一个 Java Web 应用时，你只需复用 Tomcat/Deploy 这个 Procedure，而无需重写任何逻辑。如果 Tomcat 的部署方式需要更新，你只需要修改这一个地方。

参数化是你的好朋友:
CloudBees CD/RO 的参数系统非常强大。学会使用 $[propertyName] 语法来引用属性。

$[formal_parameter_name]：引用流程的输入参数。
$[credential:credName.userName]：安全地引用凭证。
[/myEnvironment/server_ip]：从环境模型中获取属性。

4. 编排的力量：从部署到发布

CloudBees CD/RO 的 “RO” (Release Orchestration) 是它的真正亮点。一个发布（Release）不仅仅是部署一个应用，而是协调多个应用、多个团队、自动化测试、手动审批和业务决策的复杂过程。

利用发布流水线（Release Pipeline）来建模你的价值流：

阶段 (Stages): 将发布过程分解为逻辑阶段，如 SI, QA, PROD。
闸 (Gates): 在阶段之间设置自动或手动的审批门。例如，只有当自动化测试通过率 > 95% 并且 SI 经理手动批准后，才能进入 QA 阶段。
任务 (Tasks): 在每个阶段内定义具体任务，这些任务可以是并行的，也可以是串行的。
- 部署 backend-service。
- 部署 frontend-ui。
- Parallel Process（并行执行）运行集成测试。
- 通知 Jira 更新工单状态。

通过这种方式，你可以将从代码提交到生产上线的整个路径可视化、自动化和可审计。

5. 集成与插件：打造你的 DevOps 工具链

CloudBees CD/RO 不是要取代你所有现有的工具，而是要将它们“粘合”在一起。它拥有一个庞大的插件库，可以轻松与你的 DevOps 生态系统集成：

CI 服务器: 用 Jenkins/GitLab CI 做好构建和单元测试，然后触发 CloudBees CD/RO 进行部署和发布。
源码管理: 与 Git 集成，自动触发流程。
构件库: 从 Artifactory/Nexus 拉取构件。
配置管理: 调用 Ansible Playbook 或 Chef Recipe 来配置环境。
测试工具: 集成 Selenium, JMeter 等进行自动化测试，并根据结果驱动流水线。
工单系统: 与 Jira/ServiceNow 集成，实现工单状态的自动更新和关联。

总结

高效使用 CloudBees CD/RO 的核心思想是：把它当作一个开发平台，而不是一个运维工具。

建模优于脚本: 用其对象模型（应用、环境）来组织你的交付物。
代码优于点击: 全面拥抱 DSL，将你的交付流程纳入版本控制和代码审查。
抽象优于具体: 构建可重用的、模块化的 Procedure，而不是在每个应用中重复造轮子。
编排优于执行: 利用发布流水线来管理端到端的价值流，而不仅仅是单个部署任务。

将这些原则付诸实践，你的交付流程将不仅仅是自动化，更是变得可靠、可扩展且易于管理。你将从救火队员的角色，转变为交付流程的架构师。

希望这些技巧对你有用！欢迎在评论区分享你的经验和问题。

[每次突破0.1] JavaScript 如何判断属性是否存在

[yun] — Thu, 09 Jan 2025 11:01:16 +0000

前言

在 JavaScript 开发中，我们常常需要判断在于一个对象中一个属性是否存在。
由于 JavaScript 是一个比较松散的语言，导致我们很难去做一些比较严格的事。就比如这个问题，“属性是否存在”在 JavaScript 里的定义出现了偏差，到底什么时候是存在，什么是算不存在。这没有对错之分，只是在不同的语境下，不同的开发需求下，“存在”的含义是不一样的。
这里我就说一说比较常用的5种判断方式，和它们存在的问题。

方法 1：布尔（Boolean）判定

这里举个例子：

const obj1 = { name: 'Andy', age: 21 }
const obj2 = { name: 'Alice' }

console.log( obj1.age ? '存在' : '不存在' ); // 存在
console.log( obj2.age ? '存在' : '不存在' ); // 不存在

先说说这种方式的缺陷吧
如果：

const obj = { name: 'Baby', age: 0 }

console.log( obj.age ? '存在' : '不存在' ); // 不存在

这种情况下，age应是 “存在”，但是会被判断成“不存在”。

那么这种方式是不是就不能用呢？
这就要根据业务的开发需求了。
如果你知道在你的业务开发需求里，这个属性是不可能为0，空字符串啊，NaN啊，undefined之类的，那么这个判定还是可行的。
如果你放在更加严格的环境，那么这个方式就有缺陷的。

方法 2: 可选链 `(?.)` 和 `undefined` 检查

还是先举例：

const obj1 = { name: 'Andy', age: 21 }
const obj2 = { name: 'Alice' }

console.log( obj1?.age !== undefined ? '存在' : '不存在' ); // 存在
console.log( obj2?.age !== undefined ? '存在' : '不存在' ); // 不存在

这个对比的逻辑就是，在JS语言里，一个不存在的值就是undefined。

但是在一个对象里，也可能出现的这种情况：

const obj = {
    name: 'Andy',
    age: undefined
}

像这种情况，那么age这个属性应该是“存在”呢，还是“不存在”？

这也就不好说了，还是要看你的具体的需求环境。

方法 3: 查找`Object.keys()`

如果说，我就要知道一个对象里有没有一个属性age，我不管它的值是什么。

我们就可以用这个方式：

const obj = { name: 'Andy', age: 21 }

console.log( Object.keys(obj).includes('age') ? '存在' : '不存在' ); // 存在

使用Object.keys()可以得到自身的可枚举属性名来进行判断。

这里有两个关键词，一个是“自身的”（own），一个是“可枚举”（enumerable）。

首先说，什么是“自身的”

比方说这里有一个对象，给对象加一个属性name：

const obj = { name: 'Andy' }
// `name` 就是 obj 自身的属性
console.log( Object.keys(obj) ); // [ 'name' ]

那么什么不是自身的属性呢？这里就要扯到“原型”了。一个对象是有原型，在原型上加的属性就不是“自身的”属性了。

const obj = Object.create( { type: 'human' } );
obj.name = 'Andy';

console.log( obj.name ); // Andy
console.log( obj.type ); // human
console.log( Object.keys(obj) ); // [ 'name' ]

这个例子，你怎么判断type是不是obj的属性呢？这就不好说了对吧，你可以说是，也可以说不是。这就是语言宽松环境带来的问题。

但你需要知道的是，在这种情况下，Object.keys()是拿不到原型上的属性。因为它只能读取“自身的”属性。

第二个是，“可枚举”

这里就要提到属性描述符了，我很多同事都不知道，在JS语言里，在一个对象里，每个属性都有一个描述符的。
怎么读取呢？我们打印看吧：

const obj = { name: 'Andy', age: 21 };

const descriptor = Object.getOwnPropertyDescriptor(obj, 'name');

console.log( descriptor );
// { value: 'Andy', writable: true, enumerable: true, configurable: true }

你会发现，这个描述符其实也是一个对象，它描述了这个属性的一些信息，比如说值（value），可重写（writable），还有这个（enumerable）可枚举 ...

这个enumerable定义了那个属性，是否可以被枚举，比如for...in循环时候可以读取这个属性，Object.keys()也是如此。

如果我重新定义一个属性为不可枚举的，那么Object.keys()就读取不到这个属性了。

const obj = { name: 'Andy', age: 21} ;
Object.defineProperty(obj, 'age', {
    enumerable: false
});

console.log( obj.age ); // 21
console.log( Object.keys(obj) ); // [ 'name' ]

这里就涉及到了属性描述符的相关知识了，这个是原生JS语言非常重要的知识，而我发现很多我认识的前端程序员都缺乏这种原生JS的知识。

那么如果说你要判断的属性要求只要是自身的属性，不管可不可枚举呢？那么就不能用Object.keys()了。可以用接下来的方法。

方法 4：使用 `Object.hasOwn()` 或 `hasOwnProperty()`

Object.hasOwn() 和 hasOwnProperty() 有什么区别呢？

Object.hasOwn() 是 ES2022 加入的方法，用于检查对象是否自身具有某个属性，用于替代 hasOwnProperty 的促优处理。由于这是后来加入的方法，兼容性还是个问题，如果只考虑新版本的浏览器还是可以用的。

这两个方法判断的是 “自身的” 属性名，所以不管是不是可枚举，都能被读取。

const obj = {};
Object.defineProperty(obj, 'name', {
    value: 'Andy',
    enumerable: false // 不可被枚举
});

console.log( Object.hasOwn(obj, 'name') ? '存在' : '不存在' ); // 存在
console.log( obj.hasOwnProperty('name') ? '存在' : '不存在' ); // 存在

为什么要用Object.hasOwn()，由于对象的hasOwnProperty()有可能被修改：

const obj = {
    name: 'Andy',
    hasOwnProperty: ()=>false,
}

console.log( Object.hasOwn(obj, 'name') ? '存在' : '不存在' ); // 存在
console.log( obj.hasOwnProperty('name') ? '存在' : '不存在' ); // 不存在

如果你要判断的属性名，不要求是自身的和可枚举，原型也行，那么就要用最后一个方法了。

方法 5: `in` 运算符

in 运算符用于判断一个属性是否存在于对象或其原型链中。

const obj = Object.create( { name: 'Andy' } );

console.log( 'name' in obj ? '存在' : '不存在' ); // 存在
console.log( Object.hasOwn(obj, 'name') ? '存在' : '不存在' ); // 不存在

总结

这些方法种，没有说那个方法是正确的，那个错误的。并不是每个场景都适合同一种方法，根据情况遵守最佳实践，以增强代码可读性和安全性。

[每次突破0.1] Javascript中的==运算和转换

[yun] — Mon, 27 Nov 2023 05:25:07 +0000

在工作生涯中，我发现还是有很多很多Frontend Developer（前端程序猿）都不是很清楚Javascript(JS)里有一些基础的知识。这期我们就说说JS里的==运输和转换规则。
看起来很笨对吧，==运算符不就是检查其两个操作数是否相等，返回一个布尔值(boolean)结果嘛。

来我们看看下面这个题例：

if( a == 1 && a == 2 && a == 3 ) {
    console.log("恭喜你突破0.1了。");
}

现在我要你把上面的if statement成立，从而打印出恭喜你突破0.1了。，你能办到吗？

要解这道题你就要彻底的了解在JS里的==运输和转换规则。
在mdn文档有详细说明了规则，我知道很多程序猿都是很懒惰读文档，这里我就做点简介好让你跟容易理解。

我大致总结了一下，按以下规则步骤从1.到5.依序做比较，直到得到确切的结果为止：

两边相同的类型做比较，就比较值。
其中一个是NaN，直接返回false。
null和undefined只有与自身，或互相比较才会返回true。
两边不同的类型但都是基础类型，转换成数字重复步骤1.比较。
一边是原始类型，一边是对象，把对象转换成基础类型后重复步骤1.比较。

很简明对吧，现在我们就一步一步看。

第一步: 两边相同的类型做比较，就比较值。
这个很好理解吧，应该不用多解释。
就是1 == 1是true，"andy" == "cooker"是false。
这里有一点要注意以下，如果两边是对象，比较值是怎样呢？在JS里，变量里存的是对象的地址。这里比较值的意思比较两个变量的地址值是不是一样。

第二步：其中一个是NaN，直接返回false。
这个也很好理解，就一看到NaN就直接返回false。

第三步：null和undefined只有与自身，或互相比较才会返回true。
这个我就直接举例吧：

null == null // true
null == undefined // true
undefined == undefined // true
null == 0 // false
null == NaN // false

第四步：两边不同的类型但都是基础类型，转换成数字重复步骤1.比较。
如果两边类型不同又是基础类型，比如1 == true，1是Number，true是Boolean就把，true转为Number进行比较。

(1 == true)
+true // 转为Number, 是1
1 == 1 // 就是true

(1 == 'a')
+'a' // 转为Number, 是NaN
1 == NaN // 就是false

(2 == '2')
+'2' // 转为Number, 是2
2 == 2  // 就是true

第五步：一边是原始类型，一边是对象，把对象转换成基础类型后重复步骤1.比较。
这个的关键在如何把对象转换成基础类型，这里有3个步骤：

如果对象有@@toPrimitive方法，就调用做比较。如果方法返回不是基础类型，抛出异常。

const a = {
  // 如果对象有@@toPrimitive方法，就会被调用
  [Symbol.toPrimitive](){
     return 1;
  }
}

调用valueOf方法做比较，如果返回值不是基础类型，继续下一步。在JS里，所有对象默认都有valueOf方法，那么这个方法返回的是什么？默认情况下是返回对象本身。这个valueOf方法是可以自行更改的：
```
const a = {
  valueOf() {
    return 1; // 更改成返回1
  }
}
```
调用toString方法作比较，如果方法返回不是基础类型，抛出异常。

知道了第五步的规则逻辑后，我们再来接这个题是不是容易很多了。
我们再看会这个题：

( a == 1 && a == 2 && a == 3 )

我们就只要确保a能再做比较时依序返回1,2和3就可以了，那么我们可以用任何一个@@toPrimitive，valueOf 或 toString 来完成。
这里我就用valueOf来做演示：

const a = {
    count: 1,
    valueOf() {
        return this.count++;
    }
}

if( a == 1 && a == 2 && a == 3) {
    console.log("恭喜你突破0.1了。");
}

去运行看看吧。

其实这个题并不是那么重要，关键是你得理解JS的基础，在JS里等号是如何运算的。
Happy Coding.

[每次突破0.1] ES2023中数组的复制更改方法

[yun] — Sun, 24 Sep 2023 08:03:32 +0000

过去，JS数组(Array)的方法都是对原数组内容做更改的，其中包过 splice(), sort() 和 reverse()
比如：

const arr = [5, 6, 2, 7];
arr.sort();

console.log(arr); // [2, 5, 6, 7]

这对一些纯函数编程环境有点不友好，比方说React。

现在ES2023加入了几个通过复制来更改数组的方法，分别是：

toSorted(comporeFn) : 返回一个新的已排序数组
toReversed()：返回一个新的逆序数组
toSplice(start, count, ...items)：在给定的索引处删除和/或替换了一些元素，返回一个新的数组
with(index, value)：在指定索引处替换上新的值，返回一个新的数组

上面这4个新的方法都是不会对原数组做更改的，而是先进行复制在给予操作再返回已复制的新数组。

const arr = [5, 6, 2, 7];
const sortedArr = arr.toSorted();

console.log(arr); // [5, 6, 2, 7]
console.log(sortedArr); // [2, 5, 6, 7]

这推广函数式编程(Functional Programing)原则并增强代码可预测性。

如何用Windows下的Docker Desktop Kubernetes部署ForgeOps 7.2来实现本地开发

[yun] — Thu, 25 May 2023 12:32:05 +0000

前言

ForgeRock官方提供了一个DevOps方案(ForgeOps)用于展示如何部署ForgeRock Identity Platform在Kubernetes里。

很遗憾的在官方CDK文档并没有教在Windows里的Docker Desktop Kubernetes或minikube部署ForgeOps。官方给的方案是运行一个Linux虚拟机，比如使用Hyper-V, VMWare Player 或 VMWare Workstation运行Ubuntu，然后在Linux虚拟机里使用minikube来部署ForgeOps。

我个人认为为了实现本地开发而运行一个虚拟机实在是费资源。既然ForgeOps是展示在Kurbenetes上运行的，原理上无论在什么操作系统，只要我能部署一个Kubernetes cluster，我就应该能部署ForgeOps给的配置。

这里我们就尝试在Windows下的Docker Desktop Kubernetes部署ForgeOps。

安装需要的软件

如果你比较熟悉Kubernetes，其他一些小工具比如kubectx和kubens可以选择性安装。这些小工具可以提高工作效率，在这个部署中不是必要工具。

安装Docker Desktop并开启Kubernetes功能

安装我想应该非常简单，就不必我一步步指吧。在安装过程中会有一个选项询问是否要开启Kubernetes功能，只需打勾就好了。
如何你在安装中错过了，或早已安装了Docker Desktop的，就去设置目录开启Kubernetes功能就好了。

下载ForgeOps 7.2 Github源码

这里要注意每个版本的部署方式都有些许不同，这里我使用的是release/7.2.0版本。但部署原理都是一样的，只要你掌握的原理，你就可以跟着不同版本的需要做些改动来完成部署。

如果你有用Github Desktop，只需在UI上点几个button就可以下载了。
这里我用git来下载源码：

git clone https://github.com/ForgeRock/forgeops.git
cd forgeops

处理sh文件EOL问题

我在创建docker image后发现所有的docker image都运行不了，原因是forgerock的base image是使用Linux核的，而forgeops的.sh源文件是使用CRLF的，我有点搞不明白为什么。

所以我们必须先吧所有的.sh源文件从CRLF转去Linux能解读的LF。当然一个一个文件去修改实在太耗时了，这里我们就需要用到dos2unix这个小工具来帮我们批量处理了。

我个人对bash比较熟悉，就使用git-bash来完成，如果你比较熟悉PowerShell，也可以用PowerShell来完成：

find . -name "*.sh" -type f -exec dos2unix {} \;

更改imagePullPolicy

我们将使用forgeops提供的skaffold yaml来进行部署，这个skaffold包括了创建custom docker image，并用custom docker image进行部署。

然而，forgeops提供的kubernetes部署yaml都是用imagePullPolicy: Always，如果你部署在本地的Kubernetes，它会一直尝试从互联网下载image，而导致ErrImgPull image不能被下载。

这里我们就需要把所有的imagePullPolicy从Always改去IfNotPresent或Never，这样本地Kubernetes就会优先从本地查找image。

批量更改的方法很多，你就用你最适应的方法去改吧。我的方法是使用VS Code打开forgeops文件夹，然后使用Search & Replace功能，把imagePullPolicy: Always批量replace成imagePullPolicy: IfNotPresent。

检查Kubernetes

源文件的准备工作到这里就好了，现在要检查你的Kubernetes和安装的CLI能否运行。

kubectl get nodes

运行以上这个command你应该会得到docker-desktop，然后status应该要是Ready

现在就可以创建新的namespace了，这个namespace主要是用来分开ForgeRock的应用以方便我们查看。

kubectl create ns forgerock

如果你有用kubens，也可以把forgerock设置成默认namespace：

kubens forgerock

然后检查所有所需的工具能正常运行

helm
skaffold

部署secret agent和cert manager

根据官方CDK Architecture文档，ForgeRock Identity Platform还需要secret agent，cert manager 和 DS operator。

DS Operator我就不部署了，应该这个主要是用于backup和restore DS的资料，本地开发应该没用。如果你有需要也可以跟着secret agent或cert manager的部署方法。

部署secret agent

ForgeRock官方提供了secret agent的Kubernetes yaml部署文件，所以这一步非常简单。只需运行以下command就可以了：

kubectl apply -f https://github.com/ForgeRock/secret-agent/releases/download/v1.1.8/secret-agent.yaml

运行后就可以检查用kubectl get ns command检查secret-agent-system namespace是否已经创建。并检查secret-agent-controller-manager是 READY 1/1 的状体:

kubectl get deployment -n secret-agent-system

部署cert manager

ForgeOps是用开源的cert-manager.io来管理证书。forgeops也提供一个bash script方便使用helm来部署cert-manager。

这里我们可以利用git-bash来运行这个bash script：

./bin/certmanager-deploy.sh

运行完成后也是检查下cert-manager的status：

kubectl get deployment -n cert-manager

创建secrets

ForgeRock Identity Platform里用到大量的secrets，如果要一个一个创建不但麻烦费时也很复杂。这里forgeops以提供的Kustomize部署文件利用secret agent来创建需要的secrets：

kubectl apply -k .\kustomize\base\secrets -n forgerock

部署完成后，用以下command检查是不是又一堆ds-，am-，idm-的secrets以创建。

kubectl get secrets -n forgerock

部署ForgeRock

现在我们可以开始部署ForgeRock Identity Platform了，这一步非常简单，只需运行：

skaffold dev

部署Ingress Controller

完成以上的部署，接下来就是要浏览https://default.iam.example.com/am了。但是应该怎样浏览呢？

这里我们就需要Ingress Controller了，我选择了Ngix的Ingress Controller，你可以根据自己需求选择。

这里我们就用官方的部署文件吧：

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.7.1/deploy/static/provider/cloud/deploy.yaml

部署完成后就只需port-forward去Ingress Controller就可以了

kubectl port-forward --namespace=ingress-nginx service/ingress-nginx-controller 80:80

最后一步，设置host文件

想必程序员们对host文件不陌生吧，我们就只需把default.iam.example.com设成本地解析就可以了。
简单的在C:\Windows\System32\drivers\etc\hosts文件加一行：

127.0.0.1 default.iam.example.com

现在你就可以浏览 https://default.iam.example.com/am 了。

还差最后一样都东西就是登录用户和密码，哈哈。这里我就不明示怎样创建用户了，你们就琢磨琢磨，如果真的不行就在评论区留言，我会在评论区教你。

总结

经过我不断的尝试，终于找到一个可以部署ForgeOps让在Windows也能实现本地开发。这里就分享给大家，最后ForgeRock需要的内存挺多的，建议大家预留最少9GB的内存来运行。

JDK 8 -> 20 最重用的新增特性

[yun] — Sun, 09 Apr 2023 07:06:11 +0000

序

Java 8 早已经在 2014 年发布，毫无疑问 Java 8 对 Java 来说绝对算得上是一次重大版本更新，它包含了十多项语言、库、工具、JVM 等方面的十多项新特性。比如提供了语言级的匿名函数，也就是被官方称为 Lambda 的表达式语法，比如函数式接口，方法引用，重复注解。再比如 Optional 预防空指针，Stearm 流式作，LocalDateTime 时间操作等等。

如今，在2023年3月21日，Java 20已正式发布，但不是一个长期支持版本（LTS)。目前的长期支持版是Java 17。在这篇章LTS不是重点，我们把中重点放在从Java 8发展到现在的Java 20到底新增什么重要的特性。这里，我只总结了11个我个人认为重要的标准新特性（不是预览的），只要你是用Java 17，这些新特性你都能用得上。

JDK 9
- 集合工厂方法
JDK 10
- 局部类型推断
JDK 14
- Switch 表达式
- 更清晰的NPE
JDK 15
- 文本块
- ZGC: 可扩展低延迟垃圾收集器
JDK 16
- instanceof 模式匹配
- Record 类
JDK 17
- 密封类
- Switch 模式匹配 (预览)
JDK 18
- 默认 UTF-8 字符编码
总结

JDK 9

集合工厂方法

JEPS-269 : Convenience Factory Methods for Collections

在 JDK 9 中为集合的创建增加了静态工厂创建方式（Collection Factories）。这个集合工厂可以只用一行代码来创建一些较小的集合，目前支持List, Set和Map。这个方法只适合用于创建只读集合（Immutable Collection），里面的对象不可改变。

在 JDK 8 中:

Set<String> mySet = new HashSet<String>();
mySet.add("yun");
mySet.add("yyx");
mySet.add("andy");
mySet = Collections.unmodifiableSet(mySet);

而在 JDK 9 中只需：

Set<String> mySet = Set.of("yun", "yyx", "andy");

回顶部

JDK 10

局部类型推断

JEPS-286 : Local-Variable Type Inference

如何你是 Javascript 程序员，你一定熟悉var这个syntax。在 JDK 10 也加入var来实现自动推断数据类型。但这个还是和 Javascript 的var很不一样的。在 Java 里只是一个新的语法，它在编译时就把var根据转化成具体的数据类型了。

传统写法：

String str = "https://dev.to/";
URL url = new URL(str);
URLConnection con = url.openConnection();

JDK 10简化版：

var str = "https://dev.to/";
var url = new URL(str);
var con = url.openConnection();

虽然var简化了 Java 代码，但也必须知道var的使用场景和避免危险使用。比如以下的写法是有后患的：

var flag = 0; // 这里默认是int，而不是short或byte
var items = new ArrayList<>(); // 这里默认是ArrayList<Object>

OpenJDK官方也给出了LVTI的使用指南，往后我再整理一篇简介的文章。

回顶部

JDK 14

Switch 表达式

JEPS-361: Switch Expression

Switch 表达式早在 JDK 12 就推出了，而正式标准化是在 JDK 14。主要是加入了->和yeild语法在switch语法里。

传统写法：

String season;
switch(month){
    case MAR:
    case APR:
    case MAY:
        season = "spring";
        break;
    case JUN:
    case JUL:
    case AUG:
        season = "summer";
        break;
    case SEP:
    case OCT:
    case NOV:
        season = "autumn";
        break;
    case DEC:
    case JAN:
    case FEB:
        season = "winter";
        break;
    default:
        throw new IllegalArgumentException("Not a month: " + month);
}
return season;

Switch 表达式简化后：

return switch(month){
    case MAR, APR, MAY -> "spring";
    case JUN, JUL, AUG -> "summer";
    case SEP, OCT, NOV -> "autumn";
    case DEC, JAN, FEB -> "winter";
}

回顶部

更清晰的NPE

JEPS-358: Helpful NPE

在 JDK 14 之前，NullPointerException(NPE)只汇报哪一行代码导致空指针，在有多个表达式的代码里是很难知道那个对象为null。在 JDK 14，这个 exception 已加入清晰的 message 告诉你哪个对象是null。

比方这行代码，如果b是null

a.i = b.j;

在 JDK 14 之前的报错是这样的：

Exception in thread "main" java.lang.NullPointerException
    at App.main(App.java:5)

而 JDK 14 清晰的表明：

Exception in thread "main" java.lang.NullPointerException: 
    Cannot read field "j" because "b" is null
    at App.main(App.java:5)

回顶部

JDK 15

文本块

JEPS-378: Text Blocks

在 Java 里长文本字符串连接一直以来都是一个恶梦，因为不仅写起来麻烦，读起来也很恶心。终于在 JDK 15 加入了文本块。直接来看看对比把。

之前的字符串连接：

String json = "{\n" +
    "\"name\": \"" + user.name + "\",\n" +
    "\"nickname\": \"" + user.nickName + "\"\n" + 
    "}";

JDK 15 的文本块：

var json = """
        {
            "name": "%s",
            "nickname": "%s"
        }
        """.formatted(user.name, user.nickName);

回顶部

ZGC: 可扩展低延迟垃圾收集器

JEPS-377: A Scalable Low-Latency Garbage Collector

在 JDK 15，ZGC 垃圾收集器正式发布。根据 SPEC (Standard Performance Evaluation Corporation) 的测试，ZGC 拥有着不俗的性能：

而且还在 JDK 版本更新中不断优化：

那么 ZGC 那么好，为什么没有取代 G1GC 作为默认的 GC 呢？我个人认为有几个原因。GC 在 Java 里是一个很深学问，目前没有一个方案可以解决全部的使用场景。而 G1GC 已被广泛使用，表现也比较稳定，如果突然默认改了去用 ZGC 可能会出现不可预算的问题而导致大量不太了解 GC 的 Java 用户陷入困境。也有很多 Java 用户做 GC 调试只在默认 GC 上做调试，如果冒昧的升级用了不同的 GC，不读升级文档的 Java 用户酱不懂发生了什么事导致调试失效。

回顶部

JDK 16

instanceof 模式匹配

JEPS-394: Pattern Matching for instanceof

这个 Pattern Matching 的升级略为直接，就是简化了instanceof使用场景。这里直接举例：

传统写法：

if( obj instanceof String){ // 1) 检查 obj 的类
    // 2) declare 新的 String 变量 str，3) 并 cast obj 去 String 类
    String str = (String) obj; 

    // 使用 str 
}

上面的 3 步现在可以简化成 1 步了：

if( obj instanceof String str ){
    // 直接可以使用 str 
}

回顶部

Record 类

JEPS-395: Records

JDK 16 加入了record类。我相信大部分 Java 用户都用过Lombok工具库吧，这个record类和Lombok的@Data类似，它会自动编译出hashcode、equals、toString 等方法。但record是一个final class，同时所有的属性都是final修饰，所以record只有getter而已。更符合 Record 这么名词，就是不可更改（Immutable）的。

JDK 16 之前：

final class Point {
    private final int x;
    private final int y;

    Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    int x() { return x; }
    int y() { return y; }

    public boolean equals(Object o) {
        if (!(o instanceof Point)) return false;
        Point other = (Point) o;
        return other.x == x && other.y == y;
    }

    public int hashCode() {
        return Objects.hash(x, y);
    }

    public String toString() {
        return String.format("Point[x=%d, y=%d]", x, y);
    }
}

Lombok写法：

@Getter
@ToString
@EqualsAndHashCode
@AllArgsConstructor
final class Point{
    final int x;
    final int y;
}

JDK 16 record写法：

record Point(int x, int y) { }

回顶部

JDK 17

Java 17 是一个长期支持（LTS）版本，有较多的更新，这里我只列出两个我认为比较值得一提的特性。

密封类

JEPS-409: Sealed Classes

sealed 密封类用来限制class和interface的继承的机制，可以说是灵活版的final。被sealed修饰的类可以指定子类，而且sealed修饰的类的机制具有传递性，而它的子类必须使用final、sealed、non-sealed来修饰。

打个比方：

public abstract sealed class Shape
    permits Circle, Rectangle, Square, WeirdShape { ... }

public final class Circle extends Shape { ... }

public sealed class Rectangle extends Shape 
    permits TransparentRectangle, FilledRectangle { ... }

public final class TransparentRectangle extends Rectangle { ... }
public final class FilledRectangle extends Rectangle { ... }

public final class Square extends Shape { ... }

public non-sealed class WeirdShape extends Shape { ... }

回顶部

Switch 模式匹配 (预览)

JEPS-406: Pattern Matching for switch (Preview)

虽然在 JDK 16 加入了instanceof模式匹配，但有些使用场景，写起代码来还是比较麻烦的。在 JDK 17 把模式匹配引入到switch里。虽然这个是预览，但我觉得这个特性挺有用的，就说说这个用在switch里的模式匹配。

使用instanceof模式匹配：

static String formatter(Object o) {
    String formatted = "unknown";
    if (o instanceof Integer i) {
        formatted = String.format("int %d", i);
    } else if (o instanceof Long l) {
        formatted = String.format("long %d", l);
    } else if (o instanceof Double d) {
        formatted = String.format("double %f", d);
    } else if (o instanceof String s) {
        formatted = String.format("String %s", s);
    }
    return formatted;
}

新的switch写法简洁很多：

static String formatterPatternSwitch(Object o) {
    return switch (o) {
        case Integer i -> String.format("int %d", i);
        case Long l    -> String.format("long %d", l);
        case Double d  -> String.format("double %f", d);
        case String s  -> String.format("String %s", s);
        default        -> o.toString();
    };
}

回顶部

JDK 18

默认 UTF-8 字符编码

JEPS-400: UTF-8 by Default

最后提一提用纯英文写代码的不太关心的改进，而用中文写代码需要知道的，就是默认字符编码。在 JDK 18 把默认字符编码设置成了 UTF-8。这样有用字符编码的 APIs 都能在开发，操作系统和配置上保持一致性。

回顶部

总结

JDK 17 已改进与新增了挺多很有用的特性，以上是我个人认为帮助到我平日写代码的，不仅能写出更清晰的代码（readability），在性能上也有大幅的提升。
如果你还用着 JDK 8，强力建议尽快升级到 JDK 17，一般上是不会有太多的问题，必须注意的是 GC，也许默认的 GC 是使用 Serial GC，而新版是使用 G1GC。

回顶部

官方视频介绍：
https://www.youtube.com/watch?v=NA-sB3zvluE

如何修正npm/yarn的security问题

[yun] — Sat, 22 Jan 2022 07:20:19 +0000

审核程序包相关性是否存在安全漏洞

关于安全审核

根据npm官方docs：

A security audit is an assessment of package dependencies for security vulnerabilities. Security audits help you protect your package's users by enabling you to find and fix known vulnerabilities in dependencies that could cause data loss, service outages, unauthorized access to sensitive information, or other issues.

简单来说就是对package dependencies进行安全漏洞评估以确保已知安全漏洞得到修复。

安全漏洞能否自动修复？

在一定程度上是能的。npm提供了npm audit fix自动修复程序，能自动将有安全漏洞问题的dependencies更新到目前安全的兼容版本。杯具的是，yarn目前只提供了安全审核yarn audit，并没有可用的自动修复程序。所以yarn用户需要一些特殊的步骤来实现自动修复。

使用npm修复安全漏洞

使用npm审核修复略为简单，只需运行npm audit fix就能自动更新有安全漏洞的dependencies。但是，在某些情况下可能需要手动检查与更新。在这种情况下，npm通常会显示如何解决该特定dependency。

使用yarn修复安全漏洞

如前所述，yarn没有类似yarn audit fix的自动指令。因此，我们必须依靠两种方法：

1. 使用npm来解决

如果您使用的是yarn项目，则运行npm audit fix将得到以下的error：

npm ERR! code ENOLOCK
npm ERR! audit This command requires an existing lockfile.
npm ERR! audit Try creating one first with: npm i --package-lock-only
npm ERR! audit Original error: loadVirtual requires existing shrinkwrap file

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/andylow/.npm/_logs/2021-04-30T06_22_16_004Z-debug.log

我们可以跟着指示运行npm i --package-lock-only，这个指令将创建一个package-lock.json文件。

然后我们可以再次运行npm audit fix来达成自动修复。

最后，别忘了删除package-lock.json，因为它与yarn.lock会发生冲突。

2. 更新使用`yarn audit`发现的dependencies

在运行yarn audit之后，会显示哪些dependencies拥有安全漏洞以及哪个版本已经修复了漏洞。

现在来了棘手的问题。在Project中可能有多个依赖项使用相同的dependency，但是它们可能使用的版本不同。值得庆幸的是，yarn提供了选择性的dependency解决方案。

我们可以用以下的格式在package.json中定义resolutions：

/* package.json */
{
  "resolutions": {
    "<package>/**/<dependency>": "<version>"
  }
}

假设我们有一个dependency A和dependency B，并且它们都依赖于另一个dependency C。它们的关系由以下结构定义：

.
├── A
|   ├── C (3.1.3)
|   └── D
├── B
|   └── C (1.0.2)

在resolutions里可以这么写：

/* package.json */
{
  "resolutions": {
    "A/**/C": "3.1.3", 
    "B/**/C": "1.0.2"
  }
}

Javascript的5个小技巧

[yun] — Sat, 04 Dec 2021 19:23:59 +0000

删除Array中重复的值

利用Set特性。

const array = [1,2,2,3,3,3,4,4,4,4,5];
const unique = [... new Set(array)];

模板字符串

使用反引号 (` `) 来代替普通字符串中的用双引号和单引号。

const str = `Hello ${expression}!`;

const num1 = "1";
const num2 = "2";
console.log(`${num1}${num2}`); // 12

更多资讯

类转换

使用!!转换成Boolean。

const obj = { field1: "value" };
const bin = 0;

console.log( !!obj ); // true
console.log( !!bin ); // false

使用+转换成Number

const num1 = "1";
const num2 = "2";

console.log( (+num1) + (+num2) ); // 3

空值合并运算符

当需要给空值一个默认值，可以使用??。
那么为何不是||呢？因为||无法区分 false、0、空字符串 "" 和 null/undefined。

const field1 = "value";
const field2 = false;
const field3 = 0;
const field4 = null;

console.log( field1 || "default" ); // value
console.log( field2 || "default" ); // default
console.log( field3 || "default" ); // default
console.log( field4 || "default" ); // default

console.log( field1 ?? "default" ); // value
console.log( fiedl2 ?? "default" ); // false
console.log( field3 ?? "default" ); // 0
console.log( field4 ?? "default" ); // default

高级用法可以参阅这里

可选链 `?.`

使用?.简去使用if else

const obj = {
   sayHi: ()=>console.log("Hi")
}；

const empty = { };
const nullValue = null;

obj.sayHi(); // Hi
empty.sayHi(); // "'empty' undefined error"
nullValue.sayHi(); // "'nullValue' undefined error"

empty?.sayHi(); // "no error"
// equal to 
if( empty && empty.sayHi ) {
  empty.sayHi();
}

nullValue?.sayHi(); // "no error"
// equal to 
if( nullValue && nullValue.sayHi ) nullValue.sayHi();

Java UUID 之路

[yun] — Sun, 11 Apr 2021 15:02:05 +0000

什么是UUID?

UUID (Universally Unique Identifier) 是给于所有用途一个128位长的唯一值。

一般 UUID 标准使用Hex octets（十六位，八位字节）进度数字。
是由4个字符和4个“ - ”符号组成，综合长度是36个字符。
而所有位都设为0就是Nil UUID。

这里拿个栗子：
123e4567-e89b-42d3-a456-556642440000
xxxxxxxx-xxxx-Bxxx-Axxx-xxxxxxxxxxxx

A 表示确定 UUID 布局的变量。 UUID 中的所有其他位取决于变量字段中位的设置。变体由A的3个最重要位确定：

MSB1	MSB2	MSB3
0	X	X	reserved (0)
1	0	X	current variant (2)
1	1	0	reserved for Microsoft (6)
1	1	1	reserved for future (7)

举例的 UUID 中的 A 值是'a'。二进制等价物'a'（= 10xx）将变量显示为2。
B 代表版本。举例的 UUID 中的版本（B的值）是4。

Java 提供的 UUID

UUID 布局变量为2 分别有5个版本：
v1: 基于时间 (Time Based)，
v2: DCE安全性
v3，v5: 基于名称 (Name Based)
v4: 随机

Java 只提供了v3和v4 的 UUID implementation，但也提供了用于生成任何类型的UUID的构造函数：
UUID uuid = new UUID(long mostSigBits, long leastSigBits);

Java 也提供了获取 UUID 的变体和版本的方法：

UUID uuid = UUID.randomUUID();
int variant = uuid.variant();
int version = uuid.version();

接下来我们来看看不同版本的 UUID 生成。

版本 3 & 5

v3 & 5 的 UUID 使用 namespace 和 name 的 hash 来进行生成。 namespace标识符可以是域名系统（DNS），对象标识符（OID），URL等。
UUID = hash(NAMESPACE_IDENTIFIER + NAME)

那么问题来了，v3和v5有什么区别呢？那就是 hash 算法，v3 使用得是 MD5 (128位) 而 v5 使用得是 SHA-1 (160位)。

那么问题又来了，UUID 不是128位而已吗？SHA1 有160位怎么办？
简而言之，我们将生成值散列截断为128位，然后将4位替换为版本，将2位替换为变量。

Java 只提供了 UUID v3 的生成，这里我们看看 Java 生成 UUID v3 的方法：

String source = namespace + name;
 byte[] bytes = source.getBytes("UTF-8");
 UUID uuid = UUID.nameUUIDFromBytes(bytes);

版本 4

UUID v4 的生成是使用随机数作为源。 Java 是用 SecureRandom （使用不可预测的值作为种子来生成随机数以减少冲突的可能性）来实现。
Java 生成 UUID v4 非常简单：

UUID uuid = UUID.randomUUID();

我们也可以使用 SHA-256 加上随机的 UUID 来使用：

MessageDigest salt = MessageDigest.getInstance("SHA-256");
 salt.update(UUID.randomUUID().toString().getBytes("UTF-8"));
 String digest = bytesToHex(salt.digest());

总结

v3 和 v5 都具有不错的属性，不同的系统可以使用相同的 namespace 和 name 可以生成相同的UUID。用于创建分层 UUID 是不错的选择。

如果只需要简单的UUID生成，那么使用 v4 就可以了。

Java 8 Lambda 表达式简介

[yun] — Sun, 11 Apr 2021 14:41:09 +0000

Lambda 表达式是一种匿名函数(对 Java 而言这并不完全正确，但现在姑且这么认为)，简单地说，它是没有声明的方法，也即没有访问修饰符、返回值声明和名字。它是 Java 8 中最重要新特性。

Java 中的 Lambda 表达式通常使用 (arguments) -> (expression) 语法书写。以下是lambda表达式的重要特征:

可选参数：Lambda 表达式可以有零个或多个参数。
可选类型声明：不需要声明参数类型，编译器可以统一识别参数值。
可选的参数圆括号：一个参数无需定义圆括号，但多个参数需要定义圆括号。
可选的大括号：如果主体包含了一个语句，就不需要使用大括号。
可选的返回关键字：如果主体只有一个表达式返回值则编译器会自动返回值，大括号需要指定明表达式返回了一个数值。

以下是一些 Lambda 表达式的例子：

 // 无argument，直接return值
 () -> "Andy"

 // 接收一个argurment, return一个计算值
 x -> 2 * x  

 // 接收2个arguments, return一个计算值  
 (int x, int y) -> { return x – y; }  

 // 接受一个string, 并println, 不return任何值  
 (String s) -> { System.out.println(s); }

Lambda 表达式举例

 // 旧方法:
 new Thread(new Runnable() {
     @Override
     public void run() {
         System.out.println("Hello from thread");
     }
 }).start();

 // Lambda方法:
 new Thread( () -> System.out.println("Hello from thread") ).start();

以下代码的作用是打印出给定数组中的所有元素。注意，使用 Lambda 的方法不止一种。在下面的例子中，我们先是用常用的箭头语法创建 Lambda，之后，使用 Java 8 全新的双冒号(::)操作符将一个常规方法转化为 Lambda：

 // 旧方法:
 List<Integer> list = Arrays.asList(1, 2, 3, 4, 5, 6, 7);
 for(Integer n: list) {
    System.out.println(n);
 }

 // Lambda方法:
 List<Integer> list = Arrays.asList(1, 2, 3, 4, 5, 6, 7);
 list.forEach(n -> System.out.println(n));


 // ::操作
 list.forEach(System.out::println);

变量作用域

Lambda 只能引用标记了 final 的外层局部变量，这就是说不能在 lambda 内部修改定义在域外的局部变量，否则会编译错误。

在 Lambda 表达式当中不允许声明一个与局部变量同名的参数或者局部变量。

Forem: [yun]

Java 25：值得关注的新特性

🎯 为什么 Java 25 值得关注

📊 一图看完 Java 25 的主要更新

🚀 真正有感觉的 6 大实用更新

1️⃣ 冷启动提速：AOT + Method Profiling (JEP 514 / 515)

2️⃣ 更轻的对象：Compact Object Headers (JEP 519)

3️⃣ 新的线程上下文：Scoped Values (JEP 506)

4️⃣ Pattern Matching for Primitive Types (JEP 507)

5️⃣ 更轻的脚本体验：Compact Source Files (JEP 512)

6️⃣ 安全 API 补齐：KDF + PEM 支持 (JEP 510 / 470)

🧭 升级建议（20/21 → 25）

💬 总结：要不要上 Java 25？

🧠 TL;DR — 最推荐的 5 个特性

从“能用”到“好用”：高效运用CloudBees CD/RO 的使用心得

1. 核心概念：像写代码一样思考你的部署

2. “一切皆代码”：全面拥抱 DSL

3. 可重用性是关键：构建模块化的流程

4. 编排的力量：从部署到发布

5. 集成与插件：打造你的 DevOps 工具链

总结

[每次突破0.1] JavaScript 如何判断属性是否存在

前言

方法 1：布尔（Boolean）判定

方法 2: 可选链 (?.) 和 undefined 检查

方法 3: 查找Object.keys()

首先说，什么是“自身的”

第二个是，“可枚举”

方法 4：使用 Object.hasOwn() 或 hasOwnProperty()

方法 5: in 运算符

总结

[每次突破0.1] Javascript中的==运算和转换

[每次突破0.1] ES2023中数组的复制更改方法

如何用Windows下的Docker Desktop Kubernetes部署ForgeOps 7.2来实现本地开发

前言

安装需要的软件

安装Docker Desktop并开启Kubernetes功能

下载ForgeOps 7.2 Github源码

处理sh文件EOL问题

更改imagePullPolicy

检查Kubernetes

部署secret agent和cert manager

部署secret agent

部署cert manager

创建secrets

部署ForgeRock

部署Ingress Controller

最后一步，设置host文件

总结

JDK 8 -> 20 最重用的新增特性

序

Table Of Contents

JDK 9

集合工厂方法

JDK 10

局部类型推断

JDK 14

Switch 表达式

更清晰的NPE

JDK 15

文本块

ZGC: 可扩展低延迟垃圾收集器

JDK 16

instanceof 模式匹配

Record 类

JDK 17

密封类

Switch 模式匹配 (预览)

JDK 18

默认 UTF-8 字符编码

总结

如何修正npm/yarn的security问题

审核程序包相关性是否存在安全漏洞

关于安全审核

安全漏洞能否自动修复？

使用npm修复安全漏洞

使用yarn修复安全漏洞

1. 使用npm来解决

2. 更新使用yarn audit发现的dependencies

Javascript的5个小技巧

方法 2: 可选链 `(?.)` 和 `undefined` 检查

方法 3: 查找`Object.keys()`

方法 4：使用 `Object.hasOwn()` 或 `hasOwnProperty()`

方法 5: `in` 运算符

2. 更新使用`yarn audit`发现的dependencies

可选链 `?.`