- 博客(50)
- 问答 (2)
- 收藏
- 关注
RSS订阅原创 2. openems 开发
OpenEMS 开发指南（摘要） OpenEMS 是一个基于 OSGi 的模块化能源管理系统，采用 Java 21 开发，使用 Gradle + BND 构建工具。项目包含三个核心组件： Edge（端口8080）：现场能源管理 Backend（端口8079）：云端集中管理 BackendEdge（端口8078）：转发代理 项目采用模块化结构，包含： 构建系统：Gradle 配置文件和 BND 工作区配置 核心代码：分为 common、edge 和 backend 三大模块 设备驱动：包含电池、电表、充电桩等
2026-07-29 13:58:42
247
原创 1. openems 整体架构与核心概念
OpenEMS Edge 是一个周期性闭环控制引擎，其核心架构围绕五个关键对象构建：Cycle（全局时钟）、Scheduler（任务调度器）、Controller（决策单元）、Channel（数据交换媒介）和Bridge（协议适配层）。系统通过Component/Channel数据模型实现设备与业务的解耦，其中Nature接口规范了同类设备的统一语义。每个Cycle严格按"读-算-写"三段式执行，形成闭环控制。数据流分为采集链路、决策链路和控制链路三条并行路径。系统提供Bridge、Driver和Sched
2026-07-03 13:57:36
696
原创 0. openems 部署与体验
本文介绍了OpenEMS边缘计算平台的部署与基础组件配置方法。主要内容包括：1) 从GitHub获取最新jar包并准备JDK21运行环境；2) 通过Felix OSGI控制台管理模块化组件，重点说明Configuration菜单的核心作用；3) 详细演示如何配置仿真环境闭环系统，包括添加模拟电表、光伏、储能等设备，并设置平衡控制器实现动态调整；4) 提供REST API验证接口，展示系统如何通过储能充放电维持电网功率平衡。该配置构建了最小可运行系统，验证了OpenEMS对能源系统的动态调控能力。
2026-07-03 13:55:38
224
原创 3.0.2 Java 的引用
摘要：Java提供了四种引用类型来管理对象生命周期：强引用（默认）、软引用（内存不足时回收）、弱引用（GC直接回收）和虚引用（仅回收通知）。软引用曾用于缓存但因不可预测的回收导致性能问题；弱引用适用于监听器防泄漏和规范化映射；虚引用是finalize的替代方案但不应依赖。作者强调这些引用类型存在诸多问题，除非有明确必要且理解其机制，否则不建议使用，特别是软引用和虚引用在实际应用中存在严重缺陷。
2026-03-06 17:37:26
439
原创 Spring Boot Fat JAR 容器化指南
本文介绍了一种Spring Boot Fat JAR容器化方案，通过解压归档文件实现分层构建优化。传统容器化方式将整个JAR打包导致缓存效率低下，而本方案利用Fat JAR内部结构(BOOT-INF/lib、classes等目录)进行物理分离，按变更频率分层构建Docker镜像。相比官方分层JAR方案，该方法无需修改项目配置，兼容1.4+所有版本，特别适合无法升级框架或修改构建配置的遗留项目。方案还支持快照依赖隔离，进一步优化构建效率，是容器化过渡期的理想选择。
2026-03-06 17:33:34
316
原创 2.2 HotSpot 对象内存布局
HotSpot虚拟机对象内存布局采用三段式结构：对象头、实例数据和对齐填充。对象头包含Mark Word（存储锁状态、hashcode等运行时数据）和Klass Pointer（指向类元数据），数组对象还包含长度字段。64位JVM默认开启压缩指针优化，对象头为12字节。实例数据按类型宽度降序排列以优化内存使用，字段偏移量在类加载时确定。对齐填充确保对象整体大小是8字节的倍数。JDK新版本逐步优化了字段布局算法，并引入了紧凑对象头（Lilliput项目）以减少内存占用。不同锁状态下访问hashcode的代价存
2026-03-05 18:08:25
508
原创 3.0.1 计数与可达性分析
本文对比了引用计数与可达性分析两种内存回收策略。引用计数实现简单、析构时机确定，但存在写屏障开销大、级联释放不可控、无法处理循环引用等根本缺陷。各语言采用不同应对方案：Python/CPython引入循环检测器，Swift依赖程序员处理循环引用，Rust/C++将其作为显式工具。相比之下，可达性分析在多线程扩展性、吞吐量和循环引用处理方面更具优势，现代实现已能做到亚毫秒级暂停。引用计数的优点仅在对象图简单时成立，而可达性分析更适应复杂场景，成为主流托管运行时的首选方案。
2026-03-05 17:52:10
366
原创 Minecraft 服务端存档备份指南
本文提供两种Minecraft服务端存档备份方案：传统全量压缩备份和现代增量备份。传统方案使用tar命令打包压缩，适合简单服务器，但占用空间大；现代方案采用Restic工具，基于内容切片技术，仅存储变动数据块，节省空间且支持长期历史回溯。指南详细介绍了两种方案的实现方法，包括手动/自动备份脚本编写、环境配置及定时任务设置，帮助管理员根据服务器需求选择合适的备份策略，确保存档安全同时优化资源使用。特别强调备份时需停机以保证数据一致性，并提供了备份恢复的灵活性比较
2026-02-27 18:47:32
751
原创 Java的烂设计
Java在底层设计上存在多个根本性缺陷：Object类强制所有对象继承不必要的功能（如equals/hashCode、内置锁）；clone和序列化机制绕过构造函数破坏对象安全性；泛型擦除与值类型需求存在根本矛盾。这些早期设计导致现代Java项目（Valhalla、Loom等）不得不耗费大量精力解决历史遗留问题，证明"默认赋予所有对象能力"的设计哲学最终让所有对象为少数场景买单，且技术债务会随时间不断累积。
2026-02-25 15:37:47
642
原创 Minecraft 服务端 JVM 调优指南（低资源 / 非专用服务器专用）
Minecraft 低资源服务端 JVM 调优指南 本文针对2核4G/4核8G等低配置MC服务器提供JVM调优方案。核心思路是：通过放大Eden区、快速晋升老年代（SurvivorRatio=32+MaxTenuringThreshold=1）、激进并发标记（IHOP=20）和积极内存回收（SoftMaxHeapSize+周期性GC），在有限资源下优化TPS稳定性并降低长尾延迟。提供G1GC和Serial GC两套配置方案：G1适用于2G+内存，通过调整混合GC频率和内存回收策略平衡性能；Serial GC
2026-02-25 15:13:11
1883
原创 2.1 JVM对象创建
本文基于Hotspot虚拟机分析了对象创建的完整流程，主要包括以下步骤： 元数据检查：验证类是否已加载并初始化，必要时触发类加载过程 内存分配： 优先尝试TLAB（线程本地分配缓冲）快速分配 失败时通过CAS机制竞争堆内存（指针碰撞或空闲列表） 对象初始化： 内存空间清零 设置对象头（MarkWord和类指针） 构造方法执行：通过invokespecial指令调用构造函数 文中特别指出内存分配方式与GC算法强相关，并详细说明了指针碰撞和空闲列表两种分配策略。流程图清晰展示了从new指令到对象可用的完整过程，
2026-02-04 14:41:39
801
原创 1.2 HotSpot内存溢出与栈模型演进
本文对比分析了Java中StackOverflowError和OutOfMemoryError的本质区别，指出前者是调用深度越界，后者是内存容量耗尽。文章提供了两种错误的模拟代码示例，并详细介绍了诊断方法：栈溢出需分析调用栈模式，堆溢出需使用MAT工具分析dump文件。此外，还探讨了HotSpot固定大小栈的历史原因及替代方案，包括OpenJ9的双栈设计和Loom项目的栈帧拷贝技术。全文从错误现象、诊断方法到技术背景，系统性地阐述了Java内存管理的关键问题。
2026-02-04 14:38:25
549
原创 1.2 HotSpot 内存区域详解
HotSpot 是 Oracle JDK 和 OpenJDK 的默认 JVM 实现，采用自适应优化和分代垃圾收集设计。其元空间(Metaspace)取代了永久代，位于本地内存中，存储类元数据、方法字节码等。元空间使用 Chunk 链表管理内存，通过水位线机制触发堆 GC 来回收 ClassLoader 关联的内存。相比永久代，元空间不需要扫描内部引用关系，GC 效率更高。堆内存布局因 GC 算法而异，Serial/Parallel GC 采用经典分代设计，分为新生代(Eden+Survivor)和老年代，而
2026-01-26 16:52:57
607
原创 1.1 JVM 内存区域划分
JVM 内存区域分为线程共享区域（方法区、堆）和线程私有区域（虚拟机栈、本地方法栈、程序计数器）。方法区存储类元信息，堆存放对象实例和数组。HotSpot 在 JDK8+ 中用元空间替代永久代，优化了 GC 效率并解决了内存限制问题。虚拟机栈采用栈帧结构管理方法调用，而程序计数器记录线程执行位置。规范定义的是逻辑结构，实际实现（如 HotSpot）会有差异，例如元空间使用本地内存而非 JVM 进程内存。堆是 GC 主要管理区域，也是最大的内存空间。
2026-01-26 10:48:39
878
原创 LLM Agent 增强架构
本文提出用计算机系统类比来理解LLM增强架构，将LLM视为"概率CPU"，周围组件构成其操作系统。架构包含：原始上下文(寄存器)、压缩上下文(内存)、情景记忆(日志)、状态记忆(数据库)、Skill(程序)、Tool(符号表)等。执行流程中，LLM通过Tool Calling(syscall)和MCP协议(驱动层)访问外部能力。文章还探讨了Skill作为新型编程语言的特性，以及多Agent架构的协调问题。这种架构将LLM从全能模型转变为概率推理引擎，通过外部组件扩展能力，但面临非确定性执
2026-01-13 16:16:27
664
原创 Java Native Image 工程备忘录
Native Image 是 Java 在特定云原生场景下的生存手段，不是通用的性能升级方案。启动快、内存省的收益是实打实的。但动态特性受限、监控工具链断裂、Oracle 协议风险、维护复杂度上升，这些代价也是实打实的。对于大多数长生命周期、高吞吐的业务，传统 JVM 加上 AppCDS、CRaC 这些预热优化手段，仍然是性价比最高的选择。Native Image 适合的是那块细分市场：快速响应、极低资源占用、Java 资产无法重写。如果你的场景不在这个区间里，没必要为了追新而上 Native。
2026-01-13 11:34:25
759
原创 Redis 为什么这么快
Redis之所以快，主要基于四个关键设计：1)纯内存存储，牺牲持久性换取极致速度；2)单线程模型简化架构，避免锁竞争并强制规避慢操作；3)近数据计算理念，内置丰富原子操作减少网络I/O；4)底层优化如渐进式rehash、RESP协议等，平衡性能与稳定性。Redis针对热数据的简单原子操作场景进行深度优化，但这也意味着它在大数据量、复杂查询等场景可能表现不佳。其本质是通过特定假设和取舍，在特定赛道上做到极致性能。
2026-01-13 11:15:01
409
原创 Java 的云原生困局与破局
云原生时代将应用生命周期从"天/月"压缩到"秒"，使 JVM "用时间换性能"的经典设计陷入困境。Java 面临启动慢、内存占用高、预热时间长三大痛点。社区的应对呈现分裂态势：AppCDS 和 CRaC 在保留动态性前提下优化启动；GraalVM Native Image 牺牲部分动态性换取毫秒级启动；Project Leyden 探索中间路线。未来不会有统一解决方案，而是根据场景选择不同技术栈的多态并存格局。
2025-12-17 15:46:39
1073
原创 分布式API客户端模板
该文档是一个为分布式系统设计的、具备高可用性的通用API客户端模板。它封装了与外部API交互时所需的认证、请求、重试及容错逻辑，旨在解决微服务架构下高并发、网络不可靠等场景带来的挑战。其核心设计允许与外部API交互时，能够应对并容忍极端不稳定甚至完全不可预测的认证策略，同时保证系统的最终正确性和服务韧性
2025-07-23 11:44:24
944
2
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人