jdk1.8 64位(Java数组有最大长度吗)

jdk1.8 64位，Java数组有最大长度吗？

回答这个问题之前，我们先来看一下Java中数组是怎么定义的（以String类型为例）：

第一种方式，String[] = new String[8]; 第二种方式 String[] = {"a","b","c"};

这两个方式有什么区别呢，第一种方式是定义的时候，只是在堆内存中分配了8个连续的内存地址，而每个一内存地址中对应的都是null。第二种方式，也是在堆内存中分配了连续的内存空间，但是每个内存地址中，都有指向了指定的值。不管是哪种方式，我们都可以知道数组的长度是一个非负的int类型的。如果按照int类型数据的取值范围的话，理论的最大值应该是2^31-1 = 2147483647。那么实际情况真的是这样的么？

为了，弄清楚这个问题，我们去查看一下jdk8 ArrayList的源码：

我们可以很清楚地看到，jdk8中ArrayList里面定义的数组最大长度是Integer.MAX_VALUE - 8 的，而且人家也解释了：有些虚拟机在数组中保留了一些头信息，我猜应该这就是为啥减8的原因。另外人家说了，如果你尝试申请过大的数组的，可能会导致OutOfMemoryError 内存溢出这种异常。

那么，到底最大的长度是多少呢？带着这个疑问，我做了以下的测试（本测试是基于jdk8，win7，64位系统的）：

可以看出最大长度并不是像jdk8源码里面写的那样。既然是heep space 不足，我去查看了一下，运行是的参数-Xms128m -Xmx750m，也就是说最大堆内存是750M，按照这个内存去分配大小，依旧是这种问题。经过不断的测试，最终在我的机器上数值最大的长度是 524025852。这个还只是单类测试的，如果那种企业级应用的话，我猜数组的最大长度远远要比这个小。

以上就是我经过测试在我本机上的结果，对于不同的机器，不同的系统，这个数据可能不是固定的。如果大家有更好的答案或不同的见解，欢迎大家留言评论。如果对技术热爱的话，欢迎关注头条号：It界里一枚小学生。谢谢大家。

idea在mac上经常闪退？

原因分析如下：

1、内存分配不够

修改home/bin/目录下面的配置文件：

idea.exe.vmoptions idea64.exe.vmoptions

2、如果你使用的是64位Windows操作系统，强烈推荐使用idea64.exe启动(可以更改桌面快捷方式图标属性目标值)，并配上jdk1.8及以上版本。

centos7只有64位的版本？

是的。

CentOS（Community Enterprise Operating System，中文意思是：社区企业操作系统）是Linux发行版之一，它是来自于Red Hat Enterprise Linux依照开放源代码规定释出的源代码所编译而成。

由于出自同样的源代码，因此有些要求高度稳定性的服务器以CentOS替代商业版的Red Hat Enterprise Linux使用。两者的不同，在于CentOS并不包含封闭源代码软件。 CentOS Linux 是免费的及可自由派发的。每个 CentOS 版本均获得长达十年的维护（通过安全更新 —— 支持期的长短取决于 Red Hat 发行的源代码的更改）。新版本的 CentOS 大约每两年发行一次，而每个版本的 CentOS 更会定期（大概每六个月）更新一次，以便支持新的硬件。

这最终构建了一个安全的、低维护的、稳定的、高预测性的、高重复性的 Linux 环境。CentOS 项目从发布 CentOS 7.0-1406 该版本开始，CentOS 将采用新的版本号规则，其中 1406 表示为 2014年6月。CentOS 7 只提供 64 位版本。

你们公司还在用哪个版本？

谢邀！

最近这几年都在用java8，挺好用的，没打算换！11还没用上呢12就来了。看看前几天官宣：

我们来分析分析看看加了哪些新功能：

Shenandoah：低暂停时间的 GC（实验性功能）。新增了一个名为 Shenandoah 的 GC 算法，通过与正在运行的 Java 线程同时进行 evacuation 工作来减少 GC 暂停时间。使用 Shenandoah 的暂停时间与堆大小无关，这意味着无论堆是 200 MB 还是 200 GB，都将具有相同的暂停时间。

微基准测试套件。JDK 源码中新增了一套微基准测试套件，使开发人员可以轻松运行现有的微基准测试并创建新的基准测试。

Switch 表达式（预览功能）。扩展了 switch 语句，使其不仅可以作为语句（statement），还可以作为表达式（expression），并且两种写法都可以使用传统的 switch 语法，或者使用简化的“case L ->”模式匹配语法作用于不同范围并控制执行流。这些更改将简化日常编码工作，并为 switch 中的模式匹配（JEP 305）做好准备。

JVM 常量 API。引入 API 对关键类文件和运行时工件建模，特别是可从常量池加载的常量。在新的 java.lang.invoke.constant 包中定义了一系列基于值的符号引用（JVMS 5.1）类型，它们能够描述每种可加载常量。符号引用以纯 nominal 形式描述可加载常量，与类加载或可访问性上下文区分开。有些类可以作为自己的符号引用（例如 String），而对于可链接常量，定义了一系列符号引用类型（ClassDesc、MethodTypeDesc、MethodHandleDesc 和 DynamicConstantDesc），它们包含描述这些常量的 nominal 信息。

只保留一个 AArch64 实现。删除了与 arm64 相关的所有源，同时保留 32 位 ARM 实现和 64 位 aarch64。

可中止的 G1 Mixed GC。如果 G1 Mixed GC 存在超出暂停目标的可能性，则使其可中止。

G1 及时返回未使用的已分配内存。增强 G1 GC，在空闲时自动将 Java 堆内存返回给操作系统。为了实现向操作系统返回最大内存量的目标，G1 将在应用程序不活动期间定期执行或触发并发周期以确定整体 Java 堆使用情况。这将导致它自动将 Java 堆的未使用部分返回给操作系统。而在用户控制下，可以可选地执行完整的 GC，以使返回的内存量最大化。

总的来，新特性侧重点在底层，对开发来说没有太大的帮助。GC有了新的算法（http://openjdk.java.net/jeps/346），大家可以在网上看到详细介绍。也希望openJDK版本更新不要这么频繁，只考虑自己新版本的炒作噱头而忽略广大用户的感受是有欠妥当的。大家觉得呢？

大狂客，七年软甲开发，三年架构经验，持续分享技术方面的见解，希望能够和同样喜欢技术的你沟通交流！

64位系统tomcat启动闪退？

64位系统在启动Tomcat时闪退可能是以下原因导致Tomcat闪退：1.应用程序启动时可能会与系统或其他应用程序发生访问冲突，导致Tomcat闪退；2.启动Tomcat时，可能会出现Java程序版本不兼容的情况，导致Tomcat闪退；3.可能是机器内存不足，导致Tomcat无法正常启动。解决 Tomcat 闪退问题解决方法：1.检查重复启动服务可以确保Tomcat正确启动；2.检查版本兼容性，确保Java程序可以正常运行；3.对于机器内存不足的情况，可以通过清理机器或增加内存的方式来解决；4.检查Tomcat与应用程序之间的冲突，调整应用程序和Tomcat之间的交互方式。