找到
191
篇与
Java
相关的结果
- 第 34 页
-
对象和数组并不是都在堆上分配内存的。 前段时间，给星球的球友们专门码了一篇文章《深入分析Java的编译原理》，其中深入的介绍了Java中的javac编译和JIT编译的区别及原理。并在文中提到：JIT编译除了具有缓存的功能外，还会对代码做各种优化，比如：逃逸分析、 锁消除、 锁膨胀、 方法内联、 空值检查消除、 类型检测消除、 公共子表达式消除等。 有球友阅读完这部分内容后，对JVM产生了浓厚的兴趣，自己回去专门学习了一下，在学习过程中遇到一个小问题，关于Java内存分配的。所以和我在微信上做过简单的交流。主要涉及到Java中的堆和栈、数组内存分配、逃逸分析、编译优化等技术及原理。本文也是关于这部分知识点的分享。 JVM内存分配策略 关于JVM的内存结构及内存分配方式，不是本文的重点，这里只做简单回顾。以下是我们知道的一些常识： 1、根据Java虚拟机规范，Java虚拟机所管理的内存包括方法区、虚拟机栈、本地方法栈、堆、程序计数器等。 2、我们通常认为JVM中运行时数据存储包括堆和栈。这里所提到的栈其实指的是虚拟机栈，或者说是虚拟栈中的局部变量表。 3、栈中存放一些基本类型的变量数据（int/short/long/byte/float/double/Boolean/char）和对象引用。 4、堆中主要存放对象，即通过new关键字创建的对象。 5、数组引用变量是存放在栈内存中，数组元素是存放在堆内存中。 在《深入理解Java虚拟机中》关于Java堆内存有这样一段描述： 但是，随着JIT编译期的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化，所有的对象都分配到堆上也渐渐变得不那么“绝对”了。 这里只是简单提了一句，并没有深入分析，很多人看到这里由于对JIT、逃逸分析等技术不了解，所以也无法真正理解上面这段话的含义。 PS：这里默认大家都了解什么是JIT，不了解的朋友可以先自行Google了解下，或者加入我的知识星球，阅读那篇球友专享文章。 其实，在编译期间，JIT会对代码做很多优化。其中有一部分优化的目的就是减少内存堆分配压力，其中一种重要的技术叫做逃逸分析。 逃逸分析 逃逸分析(Escape Analysis)是目前Java虚拟机中比较前沿的优化技术。这是一种可以有效减少Java 程序中同步负载和内存堆分配压力的跨函数全局数据流分析算法。通过逃逸分析，Java Hotspot编译器能够分析出一个新的对象的引用的使用范围从而决定是否要将这个对象分配到堆上。 逃逸分析的基本行为就是分析对象动态作用域：当一个对象在方法中被定义后，它可能被外部方法所引用，例如作为调用参数传递到其他地方中，称为方法逃逸。 例如： public static StringBuffer craeteStringBuffer(String s1, String s2) { StringBuffer sb = new StringBuffer(); sb.append(s1); sb.append(s2); return sb; } StringBuffer sb是一个方法内部变量，上述代码中直接将sb返回，这样这个StringBuffer有可能被其他方法所改变，这样它的作用域就不只是在方法内部，虽然它是一个局部变量，称其逃逸到了方法外部。甚至还有可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问的实例变量，称为线程逃逸。 上述代码如果想要StringBuffer sb不逃出方法，可以这样写： public static String createStringBuffer(String s1, String s2) { StringBuffer sb = new StringBuffer(); sb.append(s1); sb.append(s2); return sb.toString(); } 不直接返回 StringBuffer，那么StringBuffer将不会逃逸出方法。 使用逃逸分析，编译器可以对代码做如下优化： 一、同步省略。如果一个对象被发现只能从一个线程被访问到，那么对于这个对象的操作可以不考虑同步。 二、将堆分配转化为栈分配。如果一个对象在子程序中被分配，要使指向该对象的指针永远不会逃逸，对象可能是栈分配的候选，而不是堆分配。 三、分离对象或标量替换。有的对象可能不需要作为一个连续的内存结构存在也可以被访问到，那么对象的部分（或全部）可以不存储在内存，而是存储在CPU寄存器中。 上面的关于同步省略的内容，我在《深入理解多线程（五）—— Java虚拟机的锁优化技术》中有介绍过，即锁优化中的锁消除技术，依赖的也是逃逸分析技术。 本文，主要来介绍逃逸分析的第二个用途：将堆分配转化为栈分配。 其实，以上三种优化中，栈上内存分配其实是依靠标量替换来实现的。由于不是本文重点，这里就不展开介绍了。如果大家感兴趣，我后面专门出一篇文章，全面介绍下逃逸分析。 在Java代码运行时，通过JVM参数可指定是否开启逃逸分析， -XX:+DoEscapeAnalysis ： 表示开启逃逸分析 -XX:-DoEscapeAnalysis ： 表示关闭逃逸分析 从jdk 1.7开始已经默认开始逃逸分析，如需关闭，需要指定-XX:-DoEscapeAnalysis 对象的栈上内存分配 我们知道，在一般情况下，对象和数组元素的内存分配是在堆内存上进行的。但是随着JIT编译器的日渐成熟，很多优化使这种分配策略并不绝对。JIT编译器就可以在编译期间根据逃逸分析的结果，来决定是否可以将对象的内存分配从堆转化为栈。 我们来看以下代码： public static void main(String[] args) { long a1 = System.currentTimeMillis(); for (int i = 0; i < 1000000; i++) { alloc(); } // 查看执行时间 long a2 = System.currentTimeMillis(); System.out.println("cost " + (a2 - a1) + " ms"); // 为了方便查看堆内存中对象个数，线程sleep try { Thread.sleep(100000); } catch (InterruptedException e1) { e1.printStackTrace(); } } private static void alloc() { User user = new User(); } static class User { } 其实代码内容很简单，就是使用for循环，在代码中创建100万个User对象。 我们在alloc方法中定义了User对象，但是并没有在方法外部引用他。也就是说，这个对象并不会逃逸到alloc外部。经过JIT的逃逸分析之后，就可以对其内存分配进行优化。 我们指定以下JVM参数并运行： -Xmx4G -Xms4G -XX:-DoEscapeAnalysis -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError 在程序打印出 cost XX ms 后，代码运行结束之前，我们使用[jmap][1]命令，来查看下当前堆内存中有多少个User对象： ~ jps 2809 StackAllocTest 2810 Jps ~ jmap -histo 2809 num #instances #bytes class name ---------------------------------------------- 1: 524 87282184 [I 2: 1000000 16000000 StackAllocTest$User 3: 6806 2093136 [B 4: 8006 1320872 [C 5: 4188 100512 java.lang.String 6: 581 66304 java.lang.Class 从上面的jmap执行结果中我们可以看到，堆中共创建了100万个StackAllocTest$User实例。 在关闭逃避分析的情况下（-XX:-DoEscapeAnalysis），虽然在alloc方法中创建的User对象并没有逃逸到方法外部，但是还是被分配在堆内存中。也就说，如果没有JIT编译器优化，没有逃逸分析技术，正常情况下就应该是这样的。即所有对象都分配到堆内存中。 接下来，我们开启逃逸分析，再来执行下以上代码。 -Xmx4G -Xms4G -XX:+DoEscapeAnalysis -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError 在程序打印出 cost XX ms 后，代码运行结束之前，我们使用jmap命令，来查看下当前堆内存中有多少个User对象： ~ jps 709 2858 Launcher 2859 StackAllocTest 2860 Jps ~ jmap -histo 2859 num #instances #bytes class name ---------------------------------------------- 1: 524 101944280 [I 2: 6806 2093136 [B 3: 83619 1337904 StackAllocTest$User 4: 8006 1320872 [C 5: 4188 100512 java.lang.String 6: 581 66304 java.lang.Class 从以上打印结果中可以发现，开启了逃逸分析之后（-XX:+DoEscapeAnalysis），在堆内存中只有8万多个StackAllocTest$User对象。也就是说在经过JIT优化之后，堆内存中分配的对象数量，从100万降到了8万。 除了以上通过jmap验证对象个数的方法以外，读者还可以尝试将堆内存调小，然后执行以上代码，根据GC的次数来分析，也能发现，开启了逃逸分析之后，在运行期间，GC次数会明显减少。正是因为很多堆上分配被优化成了栈上分配，所以GC次数有了明显的减少。 总结 所以，如果以后再有人问你：是不是所有的对象和数组都会在堆内存分配空间？ 那么你可以告诉他：不一定，随着JIT编译器的发展，在编译期间，如果JIT经过逃逸分析，发现有些对象没有逃逸出方法，那么有可能堆内存分配会被优化成栈内存分配。但是这也并不是绝对的。就像我们前面看到的一样，在开启逃逸分析之后，也并不是所有User对象都没有在堆上分配。
-
多线程中CountDownLatch的用法 一个同步辅助类，在完成一组正在其他线程中执行的操作之前，它允许一个或多个线程一直等待。 用给定的计数初始化 CountDownLatch。由于调用了 countDown() 方法，所以在当前计数到达零之前，await 方法会一直受阻塞。之后，会释放所有等待的线程，await 的所有后续调用都将立即返回。这种现象只出现一次——计数无法被重置。如果需要重置计数，请考虑使用 CyclicBarrier。 public class Main { protected static ExecutorService scheduler = Executors.newFixedThreadPool(5); public static CountDownLatch countDownLatch;//定义一个静态的CountDownLatch public static void main(String[] args) { countDownLatch = new CountDownLatch(5); //初始化容量， int threadNum = taskNum>8?8:taskNum; //创建八个线程，和cpu数目相等 for(int i=0;i
-
为什么阿里巴巴不建议在for循环中使用"+"进行字符串拼接 字符串，是Java中最常用的一个数据类型了。关于字符串的知识，作者已经发表过几篇文章介绍过很多，如： Java 7 源码学习系列（一）——String 该如何创建字符串，使用” “还是构造函数？ 我终于搞清楚了和String有关的那点事儿 三张图彻底了解Java中字符串的不变性 为什么Java要把字符串设计成不可变的 三张图彻底了解JDK 6和JDK 7中substring的原理及区别 Java中的Switch对整型、字符型、字符串型的具体实现细节 本文，也是对于Java中字符串相关知识的一个补充，主要来介绍一下字符串拼接相关的知识。本文基于jdk1.8.0_181。 字符串拼接 字符串拼接是我们在Java代码中比较经常要做的事情，就是把多个字符串拼接到一起。 我们都知道，String是Java中一个不可变的类，所以他一旦被实例化就无法被修改。 不可变类的实例一旦创建，其成员变量的值就不能被修改。这样设计有很多好处，比如可以缓存hashcode、使用更加便利以及更加安全等。 但是，既然字符串是不可变的，那么字符串拼接又是怎么回事呢？ 字符串不变性与字符串拼接 其实，所有的所谓字符串拼接，都是重新生成了一个新的字符串。下面一段字符串拼接代码： String s = "abcd"; s = s.concat("ef"); 其实最后我们得到的s已经是一个新的字符串了。如下图  s中保存的是一个重新创建出来的String对象的引用。 那么，在Java中，到底如何进行字符串拼接呢？字符串拼接有很多种方式，这里简单介绍几种比较常用的。 使用+拼接字符串 在Java中，拼接字符串最简单的方式就是直接使用符号+来拼接。如： String wechat = "Hollis"; String introduce = "每日更新Java相关技术文章"; String hollis = wechat + "," + introduce; 这里要特别说明一点，有人把Java中使用+拼接字符串的功能理解为运算符重载。其实并不是，Java是不支持运算符重载的。这其实只是Java提供的一个语法糖。后面再详细介绍。 运算符重载：在计算机程序设计中，运算符重载（英语：operator overloading）是多态的一种。运算符重载，就是对已有的运算符重新进行定义，赋予其另一种功能，以适应不同的数据类型。 语法糖：语法糖（Syntactic sugar），也译为糖衣语法，是由英国计算机科学家彼得·兰丁发明的一个术语，指计算机语言中添加的某种语法，这种语法对语言的功能没有影响，但是更方便程序员使用。语法糖让程序更加简洁，有更高的可读性。 concat除了使用+拼接字符串之外，还可以使用String类中的方法concat方法来拼接字符串。如： String wechat = "Hollis"; String introduce = "每日更新Java相关技术文章"; String hollis = wechat.concat(",").concat(introduce); StringBuffer 关于字符串，Java中除了定义了一个可以用来定义字符串常量的String类以外，还提供了可以用来定义字符串变量的StringBuffer类，它的对象是可以扩充和修改的。 使用StringBuffer可以方便的对字符串进行拼接。如： StringBuffer wechat = new StringBuffer("Hollis"); String introduce = "每日更新Java相关技术文章"; StringBuffer hollis = wechat.append(",").append(introduce); StringBuilder除了StringBuffer以外，还有一个类StringBuilder也可以使用，其用法和StringBuffer类似。如： StringBuilder wechat = new StringBuilder("Hollis"); String introduce = "每日更新Java相关技术文章"; StringBuilder hollis = wechat.append(",").append(introduce); StringUtils.join除了JDK中内置的字符串拼接方法，还可以使用一些开源类库中提供的字符串拼接方法名，如apache.commons中提供的StringUtils类，其中的join方法可以拼接字符串。 String wechat = "Hollis"; String introduce = "每日更新Java相关技术文章"; System.out.println(StringUtils.join(wechat, ",", introduce)); 这里简单说一下，StringUtils中提供的join方法，最主要的功能是：将数组或集合以某拼接符拼接到一起形成新的字符串，如： String []list ={"Hollis","每日更新Java相关技术文章"}; String result= StringUtils.join(list,","); System.out.println(result); //结果：Hollis,每日更新Java相关技术文章 并且，Java8中的String类中也提供了一个静态的join方法，用法和StringUtils.join类似。 以上就是比较常用的五种在Java种拼接字符串的方式，那么到底哪种更好用呢？为什么阿里巴巴Java开发手册中不建议在循环体中使用+进行字符串拼接呢？  (阿里巴巴Java开发手册中关于字符串拼接的规约) 使用+拼接字符串的实现原理 前面提到过，使用+拼接字符串，其实只是Java提供的一个语法糖， 那么，我们就来解一解这个语法糖，看看他的内部原理到底是如何实现的。 还是这样一段代码。我们把他生成的字节码进行反编译，看看结果。 String wechat = "Hollis"; String introduce = "每日更新Java相关技术文章"; String hollis = wechat + "," + introduce; 反编译后的内容如下，反编译工具为jad。 String wechat = "Hollis"; String introduce = "\u6BCF\u65E5\u66F4\u65B0Java\u76F8\u5173\u6280\u672F\u6587\u7AE0";//每日更新Java相关技术文章 String hollis = (new StringBuilder()).append(wechat).append(",").append(introduce).toString(); 通过查看反编译以后的代码，我们可以发现，原来字符串常量在拼接过程中，是将String转成了StringBuilder后，使用其append方法进行处理的。 那么也就是说，Java中的+对字符串的拼接，其实现原理是使用StringBuilder.append。 concat是如何实现的 我们再来看一下concat方法的源代码，看一下这个方法又是如何实现的。 public String concat(String str) { int otherLen = str.length(); if (otherLen == 0) { return this; } int len = value.length; char buf[] = Arrays.copyOf(value, len + otherLen); str.getChars(buf, len); return new String(buf, true); } 这段代码首先创建了一个字符数组，长度是已有字符串和待拼接字符串的长度之和，再把两个字符串的值复制到新的字符数组中，并使用这个字符数组创建一个新的String对象并返回。 通过源码我们也可以看到，经过concat方法，其实是new了一个新的String，这也就呼应到前面我们说的字符串的不变性问题上了。 StringBuffer和StringBuilder 接下来我们看看StringBuffer和StringBuilder的实现原理。 和String类类似，StringBuilder类也封装了一个字符数组，定义如下： char[] value; 与String不同的是，它并不是final的，所以他是可以修改的。另外，与String不同，字符数组中不一定所有位置都已经被使用，它有一个实例变量，表示数组中已经使用的字符个数，定义如下： int count; 其append源码如下： public StringBuilder append(String str) { super.append(str); return this; } 该类继承了AbstractStringBuilder类，看下其append方法： 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; } append会直接拷贝字符到内部的字符数组中，如果字符数组长度不够，会进行扩展。 StringBuffer和StringBuilder类似，最大的区别就是StringBuffer是线程安全的，看一下StringBuffer的append方法。 public synchronized StringBuffer append(String str) { toStringCache = null; super.append(str); return this; } 该方法使用synchronized进行声明，说明是一个线程安全的方法。而StringBuilder则不是线程安全的。 StringUtils.join是如何实现的 通过查看StringUtils.join的源代码，我们可以发现，其实他也是通过StringBuilder来实现的。 public static String join(final Object[] array, String separator, final int startIndex, final int endIndex) { if (array == null) { return null; } if (separator == null) { separator = EMPTY; } // endIndex - startIndex > 0: Len = NofStrings *(len(firstString) + len(separator)) // (Assuming that all Strings are roughly equally long) final int noOfItems = endIndex - startIndex; if (noOfItems startIndex) { buf.append(separator); } if (array[i] != null) { buf.append(array[i]); } } return buf.toString(); } 效率比较 既然有这么多种字符串拼接的方法，那么到底哪一种效率最高呢？我们来简单对比一下。 long t1 = System.currentTimeMillis(); //这里是初始字符串定义 for (int i = 0; i < 50000; i++) { //这里是字符串拼接代码 } long t2 = System.currentTimeMillis(); System.out.println("cost:" + (t2 - t1)); 我们使用形如以上形式的代码，分别测试下五种字符串拼接代码的运行时间。得到结果如下： + cost:5119 StringBuilder cost:3 StringBuffer cost:4 concat cost:3623 StringUtils.join cost:25726 从结果可以看出，用时从短到长的对比是： StringBuilder
-
Java的并发编程中的多线程问题到底是怎么回事儿？ 在我之前的一篇《再有人问你Java内存模型是什么，就把这篇文章发给他。》文章中，介绍了Java内存模型，通过这篇文章，大家应该都知道了Java内存模型的概念以及作用，这篇文章中谈到，在Java并发编程中，通常会遇到三个问题，即原子性问题、一致性问题和有序性问题。 上面一篇文章简单介绍了一下，由于各种原因会导致多线程场景下可能存在原子性、一致性和有序性问题。但是并没有深入，这篇文章就来在之前的基础上，再来看一下，并发编程中，这些问题都是哪来的？ 首先，我们还是从操作系统开始，先来了解一些基础知识。 CPU时间片 很多人都知道，现在我们用到操作系统，无论是Windows、Linux还是MacOS等其实都是多用户多任务分时操作系统。使用这些操作系统的“用户”是可以“同时”干多件事的，这已经是日常习惯了，并没觉得有什么特别。 但是实际上，对于单CPU的计算机来说，在CPU中，同一时间是只能干一件事儿的。 为了看起来像是“同时干多件事”，分时操作系统是把CPU的时间划分成长短基本相同的时间区间,即”时间片”，通过操作系统的管理，把这些时间片依次轮流地分配给各个“用户”使用。 如果某个“用户”在时间片结束之前，整个任务还没有完成，“用户”就必须进入到就绪状态，放弃CPU，等待下一轮循环。此时CPU又分配给另一个“用户”去使用。 CPU 就好像是一个电话亭，他可以开放给所有用户使用，但是他有规定，每个用户进入电话亭之后只能使用规定时长的时间。如果时间到了，用户还没打完电话，那就会被要求去重新排队。 不同的操作系统，在选择“用户”分配时间片的调度算法是不一样的，常用的有FCFS、轮转、SPN、SRT、HRRN、反馈等，由于不是本文重点，就不展开了。 这个电话亭可以允许哪个用户进入打电话是有不同的策略的，不同的电话亭规定不同，有的电话亭采用排队机制（FCFS）、有的优先分配给打电话时间最短的人（SPN）等 进程与线程 前面介绍CPU时间片的时候提到了CPU会根据不同的调度算法把时间片分配给“用户”，这里的“用户”在以前指的是进程，随着操作系统的不断发展，现在一般指线程。 在过去没有线程的操作系统中，资源的分配和执行都是由进程完成的。随着技术的发展，为了减少由于进程切换带来的开销，提升并发能力，操作系统中引入线程。把原本属于进程的工作一分为二，进程还是负责资源的分配，而线程负责执行。 也就是说，进程是资源分配的基本单位，而线程是调度的基本单位。 多线程中的并发问题 了解了以上的和硬件及操作系统有关的基础知识以后，我们再来看下，在多线程场景中有哪些并发问题。 关于并发编程中的原子性、可见性和有序性问题我在《内存模型》一文介绍过。 文中提到：缓存一致性问题其实就是可见性问题。而处理器优化是可以导致原子性问题的。指令重排即会导致有序性问题。有部分读者对这部分不是很理解。由于上一篇文章主要介绍内存模型，并没有展开分析，只是给了个结论，这里再针对这部分深入分析一下。 由于缓存一致性问题导致可见性问题，在《内存模型》中介绍的很清晰了，这里就不赘述了，主要结合本文来分析下原子性问题和有序性问题。 原子性问题 我们说原子性问题，其实指的是多线程场景中操作如果不能保证原子性，会导致处理结果和预期不一致。 前面我们提到过，线程是CPU调度的基本单位。CPU有时间片的概念，会根据不同的调度算法进行线程调度。所以在多线程场景下，就会发生原子性问题。因为线程在执行一个读改写操作时，在执行完读改之后，时间片耗完，就会被要求放弃CPU，并等待重新调度。这种情况下，读改写就不是一个原子操作。 就好像我们去电话亭打电话，一共有三个步骤，查找电话，拨号，交流。由于我们在电话亭中可以停留的时间有限，有可能刚刚找到电话号码，时间到了，就被赶出来了。 在单线程中，一个读改写就算不是原子操作也没关系，因为只要这个线程再次被调度，这个操作总是可以执行完的。但是在多线程场景中可能就有问题了。因为多个线程可能会对同一个共享资源进行操作。 比如经典的 i++ 操作，对于一个简单的i++操作，一共有三个步骤：load , add ,save 。共享变量就会被多个线程同时进行操作，这样读改写操作就不是原子的，操作完之后共享变量的值会和期望的不一致，举个例子：如果i=1,我们进行两次i++操作，我们期望的结果是3，但是有可能结果是2。 有序性问题 而且，我们知道，除了引入了时间片以外，由于处理器优化和指令重排等，CPU还可能对输入代码进行乱序执行，比如load->add->save 有可能被优化成load->save->add 。这就是有序性问题。 我们打电话的时候，除了可能被中途赶出来以外，本来正常步骤是要查找电话、拨号、交流的。但是电话亭非要给我们优化成查找电话、交流、拨号。这肯定不是我们想要的啊。 还是刚刚的i++操作，在满足了原子性的情况下，如果没有满足有序性，那么得到的结果可能也不是我们想要的。 总结 本文主要介绍了并发编程中会导致原子性和有序性问题的原因，关于可见性请参考《内存模型》。关于这三种问题的解决方案在《内存模型》也有介绍，更多的可以参考多线程相关书籍。Hollis后续也会出更多文章再深入分析，敬请期待。 参考资料 再有人问你Java内存模型是什么，就把这篇文章发给他。 服务器性能指标（二）——CPU利用率分析及问题排查 聊聊并发（五）——原子操作的实现原理
-
我说我精通字符串，面试官竟然问我Java中的String有没有长度限制！？ String是Java中很重要的一个数据类型，除了基本数据类型以外，String是被使用的最广泛的了，但是，关于String，其实还是有很多东西容易被忽略的。 就如本文我们要讨论的问题：Java中的String有没有长度限制？ 这个问题要分两个阶段看，分别是编译期和运行期。不同的时期限制不一样。 编译期 首先，我们先来合理的推断一下，当我们在代码中使用String s = “”;的形式来定义String对象的时候，””中字符的个数有没有限制呢？ 既然是合理的推断，那就要要足够的依据，所以我们可以从String的源码入手，根据public String(char value[], int offset, int count)的定义，count是int类型的，所以，char value[]中最多可以保存Integer.MAX_VALUE个,即2147483647字符。(jdk1.8.0_73) 但是，实验证明，String s = “”;中，最多可以有65534个字符。如果超过这个个数。就会在编译期报错。 public static void main(String[] args) { String s = "a...a";// 共65534个a System.out.println(s.length()); String s1 = "a...a";// 共65535个a System.out.println(s1.length()); } 以上代码，会在String s1 = “a…a”;// 共65535个a处编译失败： javac StringLenghDemo.java StringLenghDemo.java:11: 错误: 常量字符串过长 明明说好的长度限制是2147483647，为什么65535个字符就无法编译了呢？ 当我们使用字符串字面量直接定义String的时候，是会把字符串在常量池中存储一份的。那么上面提到的65534其实是常量池的限制。 常量池中的每一种数据项也有自己的类型。Java中的UTF-8编码的Unicode字符串在常量池中以CONSTANT_Utf8类型表示。 CONSTANTUtf8info是一个CONSTANTUtf8类型的常量池数据项，它存储的是一个常量字符串。常量池中的所有字面量几乎都是通过CONSTANTUtf8info描述的。CONSTANTUtf8_info的定义如下： CONSTANT_Utf8_info { u1 tag; u2 length; u1 bytes[length]; } 由于本文的重点并不是CONSTANTUtf8info的介绍，这里就不详细展开了，我们只需要我们使用字面量定义的字符串在class文件中，是使用CONSTANTUtf8info存储的，而CONSTANTUtf8info中有u2 length;表明了该类型存储数据的长度。 u2是无符号的16位整数，因此理论上允许的的最大长度是2^16=65536。而 java class 文件是使用一种变体UTF-8格式来存放字符的，null 值使用两个 字节来表示，因此只剩下 65536－ 2 ＝ 65534个字节。 关于这一点，在the class file format spec中也有明确说明： The length of field and method names, field and method descriptors, and other constant string values is limited to 65535 characters by the 16-bit unsigned length item of the CONSTANTUtf8info structure (§4.4.7). Note that the limit is on the number of bytes in the encoding and not on the number of encoded characters. UTF-8 encodes some characters using two or three bytes. Thus, strings incorporating multibyte characters are further constrained. 也就是说，在Java中，所有需要保存在常量池中的数据，长度最大不能超过65535，这当然也包括字符串的定义咯。 运行期 上面提到的这种String长度的限制是编译期的限制，也就是使用String s= “”;这种字面值方式定义的时候才会有的限制。 那么。String在运行期有没有限制呢，答案是有的，就是我们前文提到的那个Integer.MAX_VALUE ，这个值约等于4G，在运行期，如果String的长度超过这个范围，就可能会抛出异常。(在jdk 1.9之前） int 是一个 32 位变量类型，取正数部分来算的话，他们最长可以有 2^31-1 =2147483647 个 16-bit Unicodecharacter 2147483647 * 16 = 34359738352 位 34359738352 / 8 = 4294967294 (Byte) 4294967294 / 1024 = 4194303.998046875 (KB) 4194303.998046875 / 1024 = 4095.9999980926513671875 (MB) 4095.9999980926513671875 / 1024 = 3.99999999813735485076904296875 (GB) 有近 4G 的容量。
