溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊(cè)×
其他方式登錄
點(diǎn)擊 登錄注冊(cè) 即表示同意《億速云用戶服務(wù)條款》

JVM系列String.intern的性能分析

發(fā)布時(shí)間:2020-06-23 13:54:15 來(lái)源:億速云 閱讀:237 作者:清晨 欄目:開發(fā)技術(shù)

不懂JVM系列String.intern的性能分析?其實(shí)想解決這個(gè)問(wèn)題也不難,下面讓小編帶著大家一起學(xué)習(xí)怎么去解決,希望大家閱讀完這篇文章后大所收獲。

String對(duì)象有個(gè)特殊的StringTable字符串常量池,為了減少Heap中生成的字符串的數(shù)量,推薦盡量直接使用String Table中的字符串常量池中的元素。


String.intern和G1字符串去重的區(qū)別

之前我們提到了,String.intern方法會(huì)返回字符串常量池中的字符串對(duì)象的引用。

而G1垃圾回收器的字符串去重的功能其實(shí)和String.intern有點(diǎn)不一樣,G1是讓兩個(gè)字符串的底層指向同一個(gè)byte[]數(shù)組。

有圖為證:

JVM系列String.intern的性能分析

上圖中的String1和String2指向的是同一個(gè)byte[]數(shù)組。

String.intern的性能

我們看下intern方法的定義:

public native String intern();

大家可以看到這是一個(gè)native的方法。native底層肯定是C++實(shí)現(xiàn)的。

那么是不是native方法一定會(huì)比java方法快呢?

其實(shí)native方法有這樣幾個(gè)耗時(shí)點(diǎn):

  1. native方法需要調(diào)用JDK-JVM接口,實(shí)際上是會(huì)浪費(fèi)時(shí)間的。
  2. 性能會(huì)受到native方法中HashTable實(shí)現(xiàn)方法的制約,如果在高并發(fā)的情況下,native的HashTable的實(shí)現(xiàn)可能成為性能的制約因素。

舉個(gè)例子

還是用JMH工具來(lái)進(jìn)行性能分析,我們使用String.intern,HashMap,和ConcurrentHashMap來(lái)對(duì)比分析,分別調(diào)用1次,100次,10000次和1000000。

代碼如下:

@State(Scope.Benchmark)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Fork(value = 1, jvmArgsPrepend = "-XX:+PrintStringTableStatistics")
@Warmup(iterations = 5)
@Measurement(iterations = 5)
public class StringInternBenchMark {

  @Param({"1", "100", "10000", "1000000"})
  private int size;

  private StringInterner str;
  private ConcurrentHashMapInterner chm;
  private HashMapInterner hm;

  @Setup
  public void setup() {
    str = new StringInterner();
    chm = new ConcurrentHashMapInterner();
    hm = new HashMapInterner();
  }

  public static class StringInterner {
    public String intern(String s) {
      return s.intern();
    }
  }

  @Benchmark
  public void useIntern(Blackhole bh) {
    for (int c = 0; c < size; c++) {
      bh.consume(str.intern("doit" + c));
    }
  }

  public static class ConcurrentHashMapInterner {
    private final Map<String, String> map;

    public ConcurrentHashMapInterner() {
      map = new ConcurrentHashMap<>();
    }

    public String intern(String s) {
      String exist = map.putIfAbsent(s, s);
      return (exist == null) &#63; s : exist;
    }
  }

  @Benchmark
  public void useCurrentHashMap(Blackhole bh) {
    for (int c = 0; c < size; c++) {
      bh.consume(chm.intern("doit" + c));
    }
  }

  public static class HashMapInterner {
    private final Map<String, String> map;

    public HashMapInterner() {
      map = new HashMap<>();
    }

    public String intern(String s) {
      String exist = map.putIfAbsent(s, s);
      return (exist == null) &#63; s : exist;
    }
  }

  @Benchmark
  public void useHashMap(Blackhole bh) {
    for (int c = 0; c < size; c++) {
      bh.consume(hm.intern("doit" + c));
    }
  }

  public static void main(String[] args) throws RunnerException {
    Options opt = new OptionsBuilder()
        .include(StringInternBenchMark.class.getSimpleName())
        .build();
    new Runner(opt).run();
  }
}

輸出結(jié)果:

Benchmark                                 (size)  Mode  Cnt          Score          Error  Units
StringInternBenchMark.useCurrentHashMap        1  avgt    5         34.259 ±        7.191  ns/op
StringInternBenchMark.useCurrentHashMap      100  avgt    5       3623.834 ±      499.806  ns/op
StringInternBenchMark.useCurrentHashMap    10000  avgt    5     421010.654 ±    53760.218  ns/op
StringInternBenchMark.useCurrentHashMap  1000000  avgt    5   88403817.753 ± 12719402.380  ns/op
StringInternBenchMark.useHashMap               1  avgt    5         36.927 ±        6.751  ns/op
StringInternBenchMark.useHashMap             100  avgt    5       3329.498 ±      595.923  ns/op
StringInternBenchMark.useHashMap           10000  avgt    5     417959.200 ±    62853.828  ns/op
StringInternBenchMark.useHashMap         1000000  avgt    5   79347127.709 ±  9378196.176  ns/op
StringInternBenchMark.useIntern                1  avgt    5        161.598 ±        9.128  ns/op
StringInternBenchMark.useIntern              100  avgt    5      17211.037 ±      188.929  ns/op
StringInternBenchMark.useIntern            10000  avgt    5    1934203.794 ±   272954.183  ns/op
StringInternBenchMark.useIntern          1000000  avgt    5  418729928.200 ± 86876278.365  ns/op

從結(jié)果我們可以看到,intern要比其他的兩個(gè)要慢。

所以native方法不一定快。intern的用處不是在于速度,而是在于節(jié)約Heap中的內(nèi)存使用。

感謝你能夠認(rèn)真閱讀完這篇文章,希望小編分享JVM系列String.intern的性能分析內(nèi)容對(duì)大家有幫助,同時(shí)也希望大家多多支持億速云,關(guān)注億速云行業(yè)資訊頻道,遇到問(wèn)題就找億速云,詳細(xì)的解決方法等著你來(lái)學(xué)習(xí)!

向AI問(wèn)一下細(xì)節(jié)

免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI