Android StringBuffer 内存碎片优化

最新推荐文章于 2024-11-25 16:17:28 发布

AI绘画百宝箱

最新推荐文章于 2024-11-25 16:17:28 发布

阅读量931

点赞数 27

文章标签： android 开发语言

本文链接：https://blog.youkuaiyun.com/m0_59162559/article/details/136119974

版权

前言

在java代码中，字符串拼接是经常存在的事情，使用最多的地方也就是日志输出了。在手机设备上，日志的重要性可能没那么多，但是在iOT设备上，日志往往是救命稻草，因为设备种类多，最重要的是绝大部分厂商不会给你adb入口，因此，像手机领域一些删除日志指令的优化，显然不太合适。

关于内存碎片

我们知道，同一类型的对象反复创建和销毁会产生一定的内存碎片，如果回收速度较快且创建速度慢的话会出现明显的内存抖动，如果回收速度不理想，会朝着OutOfMemoryError的终极目标走去。说到这里，如果回收速度很快，是不是觉得内存抖动也没什么？显然是不正确的，事实是，任何内存碎片都是有危害的，只不过影响程度不同罢了。对于一些需要连续地址的大对象，危害最大。

注意：内存碎片触发OutOfMemoryError并不一定是内存空间不够了，也有可能是没有找到连续的内存地址。

我们来举个例子：一些超密集任务情况下LinkedList会频繁创建Node，但是相比ArrayList频繁扩容以及元素变少的时候仍然不释放内存相比，显然前者更好。但是如果任务最大数量和ArrayList容量一样，那么后者显然要比前者好得多。

因此，内存碎片中危害最大的显然是大对象。

注意：我们这里所说的内存碎片实际上是虚拟内存地址，在实际开发中，物理内存不连续是必然的事，因为涉及内存的分配其实是很复杂的，操作系统有自身的机制去处理这种问题。虚拟内存的不连续是影响app直接因素，因为用户态申请内存往往都是申请虚拟内存。补充一个知识点：在linux中，虚拟内存是可以大于物理内存的，只有写操作时才会真正申请物理内存，这就是为什么malloc申请内存后需要memset填充0或1这种数据的原因。

什么是大对象

大对象确切的说不是包含成员内存总量，而是单一对象除去引用部分超过一定阈值就称为大对象，当超过一定阈值时，就会直接分配到老年代内存区域，一般来说这个阈值默认是12K，而一般能超过此阈值的不是数组就是字符串。

但是，能方便优化的的数组类型只有8种基本类型和常量字符串。

在Android中，你使用最多的非基本类型对象就是字符串了，前面我们说过，字符串一般都有大对象的潜力，在JDK 1.7之后，对字符串常量池进行了特殊的堆空间优化，将其存储位置改为堆空间，同时对intern进行了改造，1.7之前调用intern会复制对象到常量池，1.7之后会将对象的引用添加到常量池中，以此来减少字面量字符串，也就是我们所说的字符串常量。这仅仅做到了对字符串常量的优化。然而，非常量的字符串依旧没有取得较好的优化方法。

不过在Android中，String类是空实现，google在指令执行阶段应该会做一些优化。

对于数组而言，如果他的分配过程内存不连续，相比连续内存的分配危害可能并不大，而连续地址的分配不仅耗时，而且还需要收集各种地址信息。

字符串和数组的特性就是内存连续的，因此数组碎片相比普通碎片更容易造成OOM。

StringBuffer 内存碎片问题

我们知道，javac和kotlinc负责对代码的前端编译，主要是转换代码为字节码，但是对于String的“加法（str1+ str2 … ）”对象的处理会按两种情况处理：

常量传播：

对于无引用常量直接合并为新的字符串，对于有引用的final常量同样进行合并，但是这里有个前提，只限于常量，对于final修饰的引用类型，除了字符串字面量外，包括非常量字符串在类的其他对象不进行优化。

后续我们来说常量传播，因为常量传播还涉及类和对象的初始化，会有很多面试题的解法。

final String m = "10";  
String b = "a" + "b" + 15 + m;

等价于下面代码

String b = "ab1510";

对字符串直接合并，另外m一般也会优化，因为m的已经没有存在的意义了，因此会对m进行擦除，这个优化法叫做：“常量字段消除”

通过StringBuilder拼接：

我们稍微改下，就能产生不同的效果

String m = "10";   // 或者 String m = new String("10"); 
String b = "a" + "b" + 15 + m;

等价下面代码

String m = "10";
(new StringBuilder()).append("ab15").append(m).toString();

为什么会出现这种情况呢？我们知道，String是不可变对象（不可变对象和是不是常量不是绝对关系），但是如果其本身是引用类型，为了防止引用类型多次变动，因此是不会常量传播的，必然会通过保守方式产生String才行。前端编译中，javac和kotlinc使用了StringBuilder来实现这个目的。

很多关于String加法的优化中，使用StringBuilder来代替加法，这种情况显然是还要考虑另外一种情况，如果加法连续是一整句，那么其性能是高于多句的情况。

一般来说建议写成下面的

  String str = "a="+a+", b="+b+", c="+c;

而不是

  String str = "a="+a;
  str + = ", b="+b;
  str += ", c="+c;

显然前者没必要优化，因为javac/kotlinc会帮助处理。但是后者问题就比较大大了，在整个逻辑执行完成总共需要创建3个StringBuilder，那么显然造成了不必要的内存碎片。

StringBuilder 内存碎片问题

理论上来说，普通对象的内存碎片危害可能没有那么大，因为其内存分配本身就是不需要地址连续，但是StringBuilder是不同的，我们在StringBuilder源码中就能发现，其本身持有了char数组，那么内存地址需要连续，其扩容会造成较大的内存岁。有些情况，数组可能不大，但是连续的申请空间会提高OOM的概率，

这里补充一点，char类型占2个字节，每一个字符意味着需要占2个bytes

StringBuilder 内存碎片优化

享元模式

我们知道，优化内存碎片最好的方式就是内存复用，比如Bitmap解码时的inBitmap机制，比如Message对象消息池。

不过，这里仍然有个问题，单线程中任意复出问题的机率很低，但是对于String加法这种情况，可能产生多线程竞争问题，因此，合理的调用机制非常重要。很好，你一定想到了ThreadLocal了吧，显然使用ThreadLocal是可以的，还有使用WeakHashMap也是可以的，不过这里我们使用ThreadLocal，因为这种实现逻辑会更简单，毕竟你更熟悉ThreadLocal而不是WeakHashMap。

另外，我们要知道，解决内存复用的最佳手段是“享元模式”，因此，我们这里利用享元模式来实现StringBuilder的复用。

public class StringBuilderFactory {
    final static ThreadLocal<LinkedList<StringBuilder>> pool = new ThreadLocal<LinkedList<StringBuilder>>() {
        @Nullable
        @Override
        protected LinkedList<StringBuilder> initialValue() {
            //懒加载机制，get时会判断要不要创建
            return new LinkedList<StringBuilder>();
        }
    };
    //每个线程最大持有的StringBuilder缓存数量
    public static final int MAX_ITEM_EACH_THREAD = 5;
    //被复用的StringBuilder容量不能小于10字节
    public static final int MIN_CAPACITY = 5;
   //被复用的StringBuilder容量不能大于512k，实际情况以你项目为准
    public static final int MAX_CAPACITY = 128 * 1024;

    public static StringBuilder obtain() {
        LinkedList<StringBuilder> builders = pool.get();
        if (builders == null || builders.isEmpty()) {
            return new StringBuilder();
        }
        return builders.pop();
    }
// 回收方法
    public static void recycle(StringBuilder sb) {
        if (sb == null || sb.capacity() < MIN_CAPACITY || sb.capacity() > MAX_CAPACITY) {
            return;  //小于MIN_CAPACITY的容量的对象，不回收了，意义不大
        }
        LinkedList<StringBuilder> builders = pool.get();
        if (builders.size() < MAX_ITEM_EACH_THREAD) { 
            //缓存池超过的不回收
            sb.setLength(0);
            builders.offer(sb);
        }
    }
}

替换问题

作为一个开发人员，我想你也一样，把String➕String的写法显然已经当成了一种习惯，如果让你主动去替换那么多String➕String，你心情肯定不会好。

可变参数方法

怎么办？封装成可变长方法？

我们以下面的方法为例子

public static String $(Object... arrs) {
    if (arrs != null && arrs.length != 0) {
        StringBuilder obtain = StringBuilderFactory.obtain();

        for(int i = 0; i < arrs.length; ++i) {
            obtain.append(i);
        }

        String s = obtain.toString();
        StringBuilderFactory.recycle(obtain);
        return s;
    } else {
        return null;
    }
}

那么用法

String str = $("a=",a,"b=",b,"c=",c)

这种方法显然是可以的，虽然➕变成了逗号，总之还能用。

但是，仍然不够最优：

假设我们再新增一个方法$(Object[] arrs)，那么此时会编译报错，显然，Object… arrs只不过是Object数组的变形，而字节码方法恰好说明了这点。

public varargs $S([Ljava/lang/Object;)Ljava/lang/String;

这就好比你传参数的时候又创建了数组，显然这种做法并不是最优的方法。另外我们传入的Object数组，如果走的方式是String.append(Object)，那么其性能也不太理想，不过，话说回来在一些简单的情况下，这种方法也是可以的。

但是你会发现，仍然没有写String➕String写的顺手，你大概率也不喜欢这种苦差事。

那么有没有更好的办法呢？

再谈StringBuilder扩展问题

其实作为一个开发者，一般情况下使用StringBuilder的情况是少于String➕String的，但是由于Javac和kotlinc的编译优化，使得StringBuilder用法比源代码要多很多。

那么有办法优化StringBuilder么？

一个悲观的消息是，StringBuilder是被final修饰，而其基类只有同包名可以访问，在java中，一些final的修饰使得一些类可扩展性很差，就比如URL类也是封装的很差劲，但你想去改造却非常困难。

因此，我们的优化就得另类一些了，这里我们可以通过ASM替换指令。为什么这么做呢，主要原因是编译前替换难度是比较大的，最好还是编译后替换。

基于ASM 方法替换

我们其实可以创建一个普通对象，让其代理持有StringBuilder即可，为什么这种方法可行呢？我们从前面看到，生成的代码中，以构造方法开始，以toString结束，实际上这个是非常有规律的，我们只需要在new 对象的时候替换为 StringBuilderFactory.obtain()来创建StringBuilder，在toString时进行回收即可。

String m = "10";
(new StringBuilder()).append("ab15").append(m).toString();

接下来，我们定义一个StringBuilderDelegate，下面方法没有那么完整，只实现了部分方法。

public class StringBuilderDelegate {
    StringBuilder stringBuilder;

    public StringBuilderDelegate() {
        this.stringBuilder = StringBuilderFactory.obtain();
    }
    public StringBuilderDelegate(String str) {
        this.stringBuilder = StringBuilderFactory.obtain();
        append(str);
    }
   
    public StringBuilderDelegate(int c) {
        this.stringBuilder = StringBuilderFactory.obtain();
        // 这里我们忽略自带容量的构造方法，避免太复杂的筛选
    }

    public StringBuilderDelegate append(Object obj) {
        this.stringBuilder.append(obj);
        return this;
    }

    public StringBuilderDelegate append(String str) {
        this.stringBuilder.append(str);
        return this;
    }

    public StringBuilderDelegate append(int value) {
        this.stringBuilder.append(value);
        return this;
    }
    
    //一些其他方法，因篇幅有限，你自己实现吧

    @Override
    public String toString() {
        String msg = stringBuilder.toString();
        StringBuilderFactory.recycle(stringBuilder);
        return msg;
    }
}

下一步，字节码替换，我们通过asm将StringBuilder的调用替换为StringBuilderDelegate的即可。

这里我们可以使用来实现

com.android.build.api.instrumentation.AsmClassVisitorFactory

不过，我们涉及到要替换的方法比较多，比如new StringBuilder() 也需要处理：

构造方法有多个（负责obtain）
所有的StringBuilder公开方法
toString方法（负责回收）

我们使用asm工具实现，那么转换结果要达到StringBuilder替换为StringBuilderDelegate

我们以StrinjavagBuilder#append(String str) 为例子

if (opcode == Opcodes.INVOKEVIRTUAL && owner == "java/lang/StringBuilder" && name == "append" && descriptor == "(Ljava/lang/String;)Ljava/lang/StringBuilder;") {
    mv.visitMethodInsn(
        Opcodes.INVOKESTATIC,
        "opcode/kit/StringBuilderDelegate",
        "append",
        "(Ljava/lang/String;)Lopcode/kit/StringBuilderDelegate;",
        false
    )
}

风险防范

实际上这里有一些比较大的风险就是方法逃逸，如果方法返回的是StringBuilder对象，该如何处理？另外我们使用StringBuilderDelegate也会产生内存碎片，这个怎么处理？另外，如果多次toString调用，那第后续是不是没有数据了？

对于第一个问题，这种风险很大，如果这种情况，风险其实很大，稍有处理不当就会出现问题。因此，我们需要限制替换范围，同时优化编码，减少方法逃逸。当然，private方法理论上是最安全的，只要不存在逃逸问题。
对于第二个问题，StringBuilderDelegate不属于大对象，内存分配不需要连续的地址，即便不使用StringBuilderDelegate也会有StringBuilder 创建。
第三个问题显然也是风险点，只能从编码角度处理

适用范围

存在大量拼接的的情况，循环体、方法体、线程上存在很多拼接写入的日志，这个时候要尽可能做到StringBuilder 内存复用
内存小或回收慢的情况

疑问解答

Q: StringBuilder在方法体中使用后就会回收，为什么还要优化呢？
A: StringBuilder中数据是通过char类型数组存储，需要连续的内存地址，但连续的内存地址如果快速申请或者申请多个不释放，比如一个方法体内创建多个StringBuilder对象，再去申请就很容易OOM

Q: 使用ThreadLocal 遇上线程池会有内存泄露的bug ？
A: ThreadLocal内存泄露的原因并不是ThreadLocal本身的问题，而是用法的问题，ThreadLocal泄露的两种处理方法是线程销毁或者ThreadLocal销毁。那遇上线程池本篇的用途是不是就没用了？恰恰相反，在一个app优化中，线程收敛是很重要的，理论上不应该担心这些问题，除非你一直在创建线程且无法销毁和收敛，导致内存泄露，这显然是app开发者自身的问题。正常情况下，能使用StringBuilder的线程池，下次使用StringBuilder的机率仍然很大，不会因为线程池的使用内存无限增大的。

不过对于线程池优化没有任何概念的开发者而言，我们假设线程他知道一些线程名称，可以对未知的线程通过白名单屏蔽。

public static void recycle(StringBuilder sb) {

  if(!inThreadWhiteList(Thread.currentThread())){
     return;
  }

        if (sb == null || sb.capacity() < MIN_CAPACITY || sb.capacity() > MAX_CAPACITY) {
            return;  //小于MIN_CAPACITY的容量的对象，不回收了，意义不大
        }
        LinkedList<StringBuilder> builders = pool.get();
        if (builders.size() < MAX_ITEM_EACH_THREAD) { 
            //缓存池超过的不回收
            sb.setLength(0);
            builders.offer(sb);
        }
    }
}

另外，如果实在不放心，也未必一定要使用ThreadLocal，我们可以使用一个普通的数据链表，在不同线程中使用，要记住的是是obtain和recycle需要和android.os.Message一样：使用时加锁即可。

Q: 使用本方案后代码变长了？
A：我不知道是不是说StringBuilderDelegate比StringBuilder长？实际上在字节码执行时，是没有这个长短概念，不过包体积优化可能会有影响，如果纯粹追求更短的代码，开启混淆或者重命名StringBuilderDelegate为更短的不就行了？

最后

如果想要成为架构师或想突破20~30K薪资范畴，那就不要局限在编码，业务，要会选型、扩展，提升编程思维。此外，良好的职业规划也很重要，学习的习惯很重要，但是最重要的还是要能持之以恒，任何不能坚持落实的计划都是空谈。

如果你没有方向，这里给大家分享一套由阿里高级架构师编写的《Android八大模块进阶笔记》，帮大家将杂乱、零散、碎片化的知识进行体系化的整理，让大家系统而高效地掌握Android开发的各个知识点。

相对于我们平时看的碎片化内容，这份笔记的知识点更系统化，更容易理解和记忆，是严格按照知识体系编排的。