- 博客(42)
- 问答 (2)
- 收藏
- 关注
RSS订阅原创 Minecraft 服务端存档备份指南
本文提供两种Minecraft服务端存档备份方案：传统全量压缩备份和现代增量备份。传统方案使用tar命令打包压缩，适合简单服务器，但占用空间大；现代方案采用Restic工具，基于内容切片技术，仅存储变动数据块，节省空间且支持长期历史回溯。指南详细介绍了两种方案的实现方法，包括手动/自动备份脚本编写、环境配置及定时任务设置，帮助管理员根据服务器需求选择合适的备份策略，确保存档安全同时优化资源使用。特别强调备份时需停机以保证数据一致性，并提供了备份恢复的灵活性比较
2026-02-27 18:47:32
375
原创 Java的烂设计
Java在底层设计上存在多个根本性缺陷：Object类强制所有对象继承不必要的功能（如equals/hashCode、内置锁）；clone和序列化机制绕过构造函数破坏对象安全性；泛型擦除与值类型需求存在根本矛盾。这些早期设计导致现代Java项目（Valhalla、Loom等）不得不耗费大量精力解决历史遗留问题，证明"默认赋予所有对象能力"的设计哲学最终让所有对象为少数场景买单，且技术债务会随时间不断累积。
2026-02-25 15:37:47
596
原创 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
1165
原创 2.1 JVM对象创建
本文基于Hotspot虚拟机分析了对象创建的完整流程，主要包括以下步骤： 元数据检查：验证类是否已加载并初始化，必要时触发类加载过程 内存分配： 优先尝试TLAB（线程本地分配缓冲）快速分配 失败时通过CAS机制竞争堆内存（指针碰撞或空闲列表） 对象初始化： 内存空间清零 设置对象头（MarkWord和类指针） 构造方法执行：通过invokespecial指令调用构造函数 文中特别指出内存分配方式与GC算法强相关，并详细说明了指针碰撞和空闲列表两种分配策略。流程图清晰展示了从new指令到对象可用的完整过程，
2026-02-04 14:41:39
762
原创 1.2 HotSpot内存溢出与栈模型演进
本文对比分析了Java中StackOverflowError和OutOfMemoryError的本质区别，指出前者是调用深度越界，后者是内存容量耗尽。文章提供了两种错误的模拟代码示例，并详细介绍了诊断方法：栈溢出需分析调用栈模式，堆溢出需使用MAT工具分析dump文件。此外，还探讨了HotSpot固定大小栈的历史原因及替代方案，包括OpenJ9的双栈设计和Loom项目的栈帧拷贝技术。全文从错误现象、诊断方法到技术背景，系统性地阐述了Java内存管理的关键问题。
2026-02-04 14:38:25
522
原创 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
537
原创 1.1 JVM 内存区域划分
JVM 内存区域分为线程共享区域（方法区、堆）和线程私有区域（虚拟机栈、本地方法栈、程序计数器）。方法区存储类元信息，堆存放对象实例和数组。HotSpot 在 JDK8+ 中用元空间替代永久代，优化了 GC 效率并解决了内存限制问题。虚拟机栈采用栈帧结构管理方法调用，而程序计数器记录线程执行位置。规范定义的是逻辑结构，实际实现（如 HotSpot）会有差异，例如元空间使用本地内存而非 JVM 进程内存。堆是 GC 主要管理区域，也是最大的内存空间。
2026-01-26 10:48:39
771
原创 LLM Agent 增强架构
本文提出用计算机系统类比来理解LLM增强架构，将LLM视为"概率CPU"，周围组件构成其操作系统。架构包含：原始上下文(寄存器)、压缩上下文(内存)、情景记忆(日志)、状态记忆(数据库)、Skill(程序)、Tool(符号表)等。执行流程中，LLM通过Tool Calling(syscall)和MCP协议(驱动层)访问外部能力。文章还探讨了Skill作为新型编程语言的特性，以及多Agent架构的协调问题。这种架构将LLM从全能模型转变为概率推理引擎，通过外部组件扩展能力，但面临非确定性执
2026-01-13 16:16:27
554
原创 Java Native Image 工程备忘录
Native Image 是 Java 在特定云原生场景下的生存手段，不是通用的性能升级方案。启动快、内存省的收益是实打实的。但动态特性受限、监控工具链断裂、Oracle 协议风险、维护复杂度上升，这些代价也是实打实的。对于大多数长生命周期、高吞吐的业务，传统 JVM 加上 AppCDS、CRaC 这些预热优化手段，仍然是性价比最高的选择。Native Image 适合的是那块细分市场：快速响应、极低资源占用、Java 资产无法重写。如果你的场景不在这个区间里，没必要为了追新而上 Native。
2026-01-13 11:34:25
656
原创 Redis 为什么这么快
Redis之所以快，主要基于四个关键设计：1)纯内存存储，牺牲持久性换取极致速度；2)单线程模型简化架构，避免锁竞争并强制规避慢操作；3)近数据计算理念，内置丰富原子操作减少网络I/O；4)底层优化如渐进式rehash、RESP协议等，平衡性能与稳定性。Redis针对热数据的简单原子操作场景进行深度优化，但这也意味着它在大数据量、复杂查询等场景可能表现不佳。其本质是通过特定假设和取舍，在特定赛道上做到极致性能。
2026-01-13 11:15:01
366
原创 Java 的云原生困局与破局
云原生时代将应用生命周期从"天/月"压缩到"秒"，使 JVM "用时间换性能"的经典设计陷入困境。Java 面临启动慢、内存占用高、预热时间长三大痛点。社区的应对呈现分裂态势：AppCDS 和 CRaC 在保留动态性前提下优化启动；GraalVM Native Image 牺牲部分动态性换取毫秒级启动；Project Leyden 探索中间路线。未来不会有统一解决方案，而是根据场景选择不同技术栈的多态并存格局。
2025-12-17 15:46:39
966
原创 分布式API客户端模板
该文档是一个为分布式系统设计的、具备高可用性的通用API客户端模板。它封装了与外部API交互时所需的认证、请求、重试及容错逻辑，旨在解决微服务架构下高并发、网络不可靠等场景带来的挑战。其核心设计允许与外部API交互时，能够应对并容忍极端不稳定甚至完全不可预测的认证策略，同时保证系统的最终正确性和服务韧性
2025-07-23 11:44:24
915
2原创 java如何跳出嵌套循环
前言首先先预设一个场景吧，假设我想在二位随机数组中取出特定数字第一次出现的位置，显然找到这个数字后就应该跳出两层循环，但单纯的break是做不到的，那么便有了这篇文章。//下面的例子用到的数组，其中要找的数字是3public static final int[][] NUMBER ={ {26, 52, 99, 65, 82, 33, 66, 56, 70, 95}, {66, 18, 3, 0, 99, 84, 72, 88, 43, 51}, {8, 54, 25, 68
2021-10-07 16:05:16
794
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人