浅谈StringBuffer构造方法及扩容

目录

  1. StringBuffer的构造方法
  2. StringBuffer的扩容

StringBuffer的构造方法

这是StringBuffer的类图,StringBuffer继承AbstractStringBuilder。StringBuffer中的构造方法都调用了其父类的构造方法,因此在了解StringBuffer的构造方法前有必要了解一下它们俩的成员变量。

以上是AbstractStringBuilder的三个成员变量,value用来存储字符,count代表使用的字符数;MAX_ARRAY_SIZE是最大的分配容量,即2^31-9,若想分配超过这个数字的容量将会报OutOfMemoryError的错误:请求的数组大小超过VM限制。

以上的StringBuffer的一个成员变量,toString方法将会返回它最后的值,当StringBuffer被修改时它将会被清空。

StringBuffer类可以创建可修改的字符串序列。该类有StringBuffer(),StringBuffer(int size),StringBuffer(String s),StringBuffer(CharSequence seq)构造方法。

1.StringBuffer()的初始容量可以容纳16个字符,当该对象的实体存放的字符的长度大于16时,实体容量就自动增加。StringBuffer对象可以通过length()方法获取实体中存放的字符序列长度,通过capacity()方法来获取当前实体的实际容量。

2.StringBuffer(int size)可以指定分配给该对象的实体的初始容量参数为参数size指定的字符个数。当该对象的实体存放的字符序列的长度大于size个字符时,实体的容量就自动的增加。以便存放所增加的字符。

3.StringBuffer(String s)可以指定给对象的实体的初始容量为参数字符串s的长度额外再加16个字符。当该对象的实体存放的字符序列长度大于size个字符时,实体的容量自动的增加,以便存放所增加的字符。

4.StringBuffer(CharSequence seq)当传入一个CharSequence变量时,会调用StringBuffer(int capacity)方法,初始大小为seq的长度加16,同时初始内容为seq的StringBuffer对象。

 

StringBuffer的扩容

扩容策略(2*n + 2):

StringBuffer在内部维护一个字符数组,当你使用缺省的构造函数来创建StringBuffer对象的时候,因为没有设置初始化字符长度,StringBuffer的容量被初始化为16个字符,也就是说缺省容量就是16个字符。
当StringBuffer达到最大容量的时候,它会将自身容量增加到当前的2倍再加2,也就是(2旧值+2)。
如果你使用缺省值,初始化之后接着往里面追加字符,在你追加到第16个字符的时候它会将容量增加到34(2*16+2),当追加到34个字符的时候就会将容量增加到70(2*34+2)。

扩容源码:

StringBuffer和StringBuilder类都继承了抽象类AbstractStringBuilder类;源码都调用父类来进行初始化:

 StringBuffer(String s)的初始化:

扩容算法:

使用append()方法在字符串后面追加东西的时候,如果长度超过了该字符串存储空间大小了就需要进行扩容:构建新的存储空间更大的字符串,将久的复制过去;
 
再进行字符串append添加的时候,会先计算添加后字符串大小,传入一个方法:ensureCapacityInternal 这个方法进行是否扩容的判断,需要扩容就调用expandCapacity方法进行扩容:


尝试将新容量扩为大小变成2倍+2   if 判断一下 容量如果不够,直接扩充到需要的容量大小。

 

 

作者:Roger_CoderLife

链接:https://blog.youkuaiyun.com/Roger_CoderLife/article/details/95179792

本文为Roger_CoderLife的原创文章,著作权归作者所有,转载请注明原文出处,欢迎转载!

### WSL 卡死的原因分析 WSL(Windows Subsystem for Linux)卡死通常由多种原因引起,主要包括资源分配不足、网络配置冲突以及底层系统兼容性问题。以下是具体可能的原因: 1. **锁屏引起的进程挂起** 当 Windows 锁屏时,某些后台服务可能会被暂停或中断,这可能导致 WSL 进程进入非响应状态[^1]。 2. **网络模式设置不当** 如果 `.wslconfig` 文件中的 `networkingMode=mirrored` 参数存在,可能会导致网络代理同步出现问题,从而引发特定指令执行时的卡顿现象[^2]。 3. **Docker 和 WSL 的交互问题** 在 WSL 2 中运行 Docker 时,如果未正确配置 IP 地址池或者静态 IP 导致网络冲突,也可能使整个 WSL 环境变得不稳定甚至卡死[^3]。 --- ### 解决方法汇总 #### 方法一:管理员权限下强制终止并重启 WSL 当 WSL 因锁屏或其他未知原因卡死后,可以通过以下 PowerShell 命令强行结束受影响的容器实例,并重新启动 WSL: ```powershell hcsdiag kill @(hcsdiag list | Select-Object -First 1) ``` 此命令会清理掉当前处于异常状态的虚拟机实例,之后通过简单关闭再打开终端的方式即可恢复正常使用[^1]。 #### 方法二:调整 WSL 的网络配置 对于因 `networkingMode=mirrored` 引发的问题,建议编辑位于 `C:\Users\<你的用户名>\.wslconfig` 的全局配置文件,移除该参数或将它改为其他更合适的选项。例如: ```plaintext [wsl2] memory=4GB # 设置内存上限 processors=2 # 分配 CPU 核心数 localhostForwarding=true # 启用本地端口转发 ``` 完成修改后记得先停止所有正在运行的 WSL 实例: ```bash wsl --shutdown ``` 随后再次尝试访问目标环境来验证效果[^2]。 #### 方法三:优化 Docker Daemon 配置防止阻塞 针对涉及 Docker 使用场景下的性能瓶颈或冻结状况,需特别关注其内部 JSON 配置文档的内容结构合理性。比如增加自定义地址范围避免潜在重叠干扰: ```json "default-address-pools": [ { "base": "192.168.0.0/16", "size": 24 } ], ``` 以上片段展示了如何指定基础子网掩码长度为 /16 ,单个区块大小设为 256 台设备容量 (即每段有 2^8 = 256 个可用 IP),这样能够有效减少与其他软件争夺相同区间的风险[^3]。 最后一步同样需要调用 `wsl --shutdown` 来刷新改动后的设定生效情况。 --- ### 总结 综合来看,处理 WSL 卡死的关键在于识别具体的触发因素——无论是操作系统层面的行为习惯还是第三方应用间的协作关系都不可忽视。采取针对性措施逐一排查直至恢复正常运作才是长久之计。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值