StringBuffer与StringBuilder源代码分析

背景想了解StringBuffer与StringBuilder之间的差别以及他们是通过何种方式去实现其功能的。差别大致了解,线程安全与不安全。更感兴趣的是其实现方式。AbstractStringBuilder两者都继承自此抽象类。该类提供了一些StringBuffer与StringBuilder公用

背景

想了解StringBufferStringBuilder之间的差别以及他们是通过何种方式去实现其功能的。差别大致了解,线程安全与不安全。更感兴趣的是其实现方式。

AbstractStringBuilder

两者都继承自此抽象类。该类提供了一些StringBuffer与StringBuilder公用的方法。

StringBuffer

public StringBuffer() {
  super(16);
}

public StringBuffer(int capacity) {
  super(capacity);
}

public StringBuffer(String str) {
  super(str.length() + 16);
  append(str);
}

public StringBuffer(CharSequence seq) {
  this(seq.length() + 16);
  append(seq);
}

一般常用到的两个构造函数为第一、三个。从上面来看,其默认的长度为16。这个16是一个什么的值呢,查看其super,如下:

/**
* Creates an AbstractStringBuilder of the specified capacity.
*/
AbstractStringBuilder(int capacity) {
  value = new char[capacity];
}

其背后的实现只是一个char[],没有其他了吗?回头继续往下看其如何进行append(),由于该方法有很多个重载方法,因此选择一个经常用的其参数为String的来看,如下:

// StringBuffer.java
@Override
public synchronized StringBuffer append(String str) {
    toStringCache = null;
    super.append(str);
    return this;
}
// AbstractStringBuilder.java
public AbstractStringBuilder append(String str) {
    if (str == null)
        return appendNull();
    int len = str.length();
    ensureCapacityInternal(count + len);
    str.getChars(0, len, value, count);
    count += len;
    return this;
}

其中count为当前StringBuffer中已存在的字符数,len为当前String的长度。很显然ensureCapacityInternal(count + len);是为了不让之前的字符数组溢出。获取这算是其核心之一吧,很值得去看看。如下:

// AbstractStringBuilder.java
private void ensureCapacityInternal(int minimumCapacity) {
    // overflow-conscious code
    if (minimumCapacity - value.length > 0) {
        value = Arrays.copyOf(value, newCapacity(minimumCapacity));
    }
}

private int newCapacity(int minCapacity) {
    // overflow-conscious code
    int newCapacity = (value.length << 1) + 2;
    if (newCapacity - minCapacity < 0) {
        newCapacity = minCapacity;
    }
    return (newCapacity <= 0 || MAX_ARRAY_SIZE - newCapacity < 0)
        ? hugeCapacity(minCapacity)
        : newCapacity;
}

private static final int MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8;

private int hugeCapacity(int minCapacity) {
    if (Integer.MAX_VALUE - minCapacity < 0) { // overflow
        throw new OutOfMemoryError();
    }
    return (minCapacity > MAX_ARRAY_SIZE)
        ? minCapacity : MAX_ARRAY_SIZE;
}

// Integer.java
public static final int   MAX_VALUE = 0x7fffffff;

// Arrays.java
public static char[] copyOf(char[] original, int newLength) {
    char[] copy = new char[newLength];
    System.arraycopy(original, 0, copy, 0,
                     Math.min(original.length, newLength));
    return copy;
}
// 再往下就是native方法了
public static native void arraycopy(
	Object src,  int  srcPos, Object dest, int destPos,int length);

也就是说,每次append都会返回一个新的包含此前char[]中数据的char[]数组,此时的数组长度已经被x2+2。

然后调用String的getChars(int srcBegin, int srcEnd, char dst[], int dstBegin)方法,将此字符串,添加到目标数组中。在此有个困惑,每次返回来的数组长度已经变了,可是在StringBuffer中调用capacity()方法显示长度只是变成了添加了字符串之后的长度。是因为那个native方法吗?应该是吧。

线程安全

这大概就是append的过程了。仔细想想,如果是这样操作的话,多线程的环境下可能会出现一些问题。因此,大部分的StringBuffer中的方法都加上了synchronized关键字,因此它就是线程安全的了。在看StringBuilder,没有。其操作基本上是使用AbstractStringBuilder类的方法。在两者的对应方法中,只是加了/没加同步关键字的差别吧。StringBuilder的代码就不贴了。

Read more

Volcano 与 Kubernetes GPU 调度学习笔记

本笔记系统整理 Volcano 调度器、Kubernetes 调度框架、GPU Device Plugin、HAMi 等云原生 AI 调度领域的核心知识,适合用于学习、复习和工程实践参考。 目录 * 第一部分:Volcano 入门 * 1. Volcano 是什么 * 2. 安装与快速使用 * 3. 核心特性一览 * 第二部分:Volcano 整体架构 * 4. Volcano 解决的核心问题 * 5. 整体架构与数据流 * 6. 三层抽象模型 * 第三部分:Volcano 核心实现原理 * 7. Session 机制 * 8. Gang Scheduling 实现 * 9. Queue 与 DRF 公平调度

容器镜像(4):镜像的常用工具箱

容器镜像(4):镜像的常用工具箱

前几篇在讲多架构镜像时已经用过 skopeo 和 crane 做镜像复制,这篇系统整理这两个工具的完整能力,同时介绍几个日常操作镜像时同样好用的工具。 一、skopeo:不依赖 Daemon 的镜像瑞士军刀 skopeo 的核心价值是绕过 Docker daemon,直接与 Registry API 交互。上一篇用它做镜像复制和离线传输,但它的能力远不止于此。 1.1 安装 # Ubuntu / Debian sudo apt install -y skopeo skopeo --version # skopeo version 1.15.1 1.2 inspect:免拉取检查镜像元数据 docker inspect 需要先把镜像拉到本地,skopeo inspect 直接向 Registry

容器镜像(3):多架构镜像构建

容器镜像(3):多架构镜像构建

一、什么是多架构镜像 1.1 OCI Image Index 上一篇介绍了单平台镜像的结构:一个 Manifest 指向 Config 和若干 Layer blob。多架构镜像在此之上多了一层——OCI Image Index(也叫 Manifest List),是一个轻量的索引文件,把多个单平台 Manifest 组织在一起: $ docker manifest inspect golang:1.22-alpine { "schemaVersion": 2, "mediaType": "application/vnd.oci.image.index.v1+json", "manifests&

容器镜像(2):containerd 视角下的镜像

容器镜像(2):containerd 视角下的镜像

一、为什么需要了解 containerd 如果你只用 docker run 跑容器,从来不关心底层,那可以不了解 containerd。但如果你在用 Kubernetes,或者想真正理解"容器运行时"是什么,containerd 是绕不开的。 事实上,当你执行 docker run 的时候,containerd 早就在后台悄悄工作了——Docker 从 1.11 版本开始,就把核心运行时剥离出来交给 containerd 负责。 1.1 Docker 的架构演变 早期的 Docker(1.10 及之前)是一个"大一统"的单体程序:一个 dockerd