Hexo

类加载与双亲委派机制Java 在刚刚诞生之时曾经提出过一个非常著名的宣传口号“一次编写，到处运行 （Write Once，Run Anywhere）。为了实现这个口号，各种不同平台的 Java 虚拟机，以及所有平台都支持一种程序存储格式—字节码（Byte Code）。 需要指出的一点是：商业企业和开源机构已经在 Java 语言之外发展出一大批运行在 Java 虚拟机之上的语言，如 Kotlin、C

增量更新与原始快照Java 语言的垃圾回收一直有一个为人所诟病的点，即垃圾回收时会触发 “STW”，为了减少 “STW” 的时间，垃圾收集器也在不断改进。 在日常开发中，我们经常会通过多线程的手段缩短程序的执行时间，目前主流的垃圾收集器也使用了并发在某些阶段让 GC线程 和 用户线程 可以同时工作，以尽可能及时地对请求进行处理。 提到并发，那就一定会涉及线程安全问题。试想：如果一个扫地机器人（GC

垃圾收集器收集算法是内存回收的方法论，而垃圾收集器是内存回收的实践者。 JDK8 时，默认收集器组合是（Parallel Scavenge + Parallel Old），JDK 9 之后，（Serial，CMS） 以及（ParNew，Serial Old）的组合已经被废弃了，默认收集器也变成了 G1。 垃圾回收就像打扫房间一样，当你在打扫房间的时候同时又在制造垃圾，那么房间很难打扫干净，因此

垃圾回收方法论垃圾收集（Garbage Collect）也就是常说的 GC，GC 这个概念不是 Java 独有的，在 Java 之前已经有其他语言有 GC 的理念了，1960 年诞生于麻省理工学院的 Lisp 是第一门开始使用内存动态分配和垃圾收集技术的语言。 垃圾收集需要考虑以下这些事情： 回收什么区域的内存? 如何判断内存可回收? 怎么回收? 回收什么区域的内存Java 的内存区域被分为程

Java对象Java 是一门面向对象的编程语言，Java 程序运行过程中无时无刻都有对象被创建出来。 对象的组成在 HotSpot 虚拟机里，对象在堆内存中的存储布局可以划分为三个部分：**对象头（Header）、实例数据（Instance Data）和对齐填充（Padding）**。 对象头中存储的是与对象自身定义的数据无关的信息，包括：对象自身运行时数据和类型指针两部分。 对象运行时数据如哈希

JVM 内存结构Java 虚拟机在执行 Java 程序的过程中会把它所管理的内存划分为若干个不同的数据区域。根据《Java虚拟机规范》的规定，Java 虚拟机所管理的内存将会包括以下几个运行时数据区域： 程序计数器在 Java 虚拟机的概念模型里，程序计数器存的是下一条需要执行的字节码指令的地址，由于 Java 的多线程是通过分配处理器执行时间的方式来实现，所以为了在切换线程时保留执行状态（执行

设计模式中的经典设计原则设计模式中有一些经典的设计原则，包括：SOLID、KISS、YAGNI、DRY、LOD 等。 其中 SOLID 分别对应 单一职责原则、开闭原则、里式替换原则、接口隔离原则 和 依赖反转原则。 单一职责原则Single Responsibility Principle：A class or module should have a single reponsibility，

面向对象设计指南一般说设计模式都是指面向对象的设计模式，因为面向对象语言可以借助封装、继承、多态等特性更好的达到复用性、可拓展性、可维护性。 面向对象一般指以类、对象为组织代码的基本单元，并将封装、继承、多态、抽象四个特性（抽象有的定义里并不认为是四大特性）作为代码设计与实现的基石。 封装：通过访问权限控制，只对外暴露必要的操作，保护数据； 继承：代码复用，结构美感。不过 Java 语言不支持

Redis源码分析之ziplist篇如果提到双向链表，我们应该很熟悉，每一个对象都有三个字段 指向前驱节点的指针； 指向后向节点的指针； 该节点的数据。 双向链表可以在两端执行 O(1) 级别的操作，缺点是可能产生内存碎片，对空间利用率低（每个节点除了存储数据还要存指向相邻节点的指针） 而 ziplist 就是一个特殊编码的双向链表，它特殊在哪里呢？ ziplist 每个节点没有使用前后指针

Redis源码分析之robj篇在 Redis 中，一个 database 内的这个映射关系是用一个 dict 来维护的（ht[0]）。dict 的 key 固定用一种数据结构来表达就够了，即动态字符串 sds。而 value 则比较复杂，为了在同一个 dict 内能够存储不同类型的 value，需要一个通用的数据结构，这个通用的数据结构就是 robj（全称 RedisObject ）。 12345