java性能优化之代码缓存优化

目录
  • JIT编译器版本
    • 默认情况JVM如何选择编译器？
    • 如何判断当前环境jvm使用的编译器？
  • 代码缓存
    • 代码缓存占满发生在什么情况？
    • 代码缓存默认大小
    • 如何确定正好的代码缓存？
    • 如何监控代码缓存？

JIT编译器版本

JIT编译器有不同的版本，而最终你使用哪种，取决于你所使用的系统平台。前面的文章我们说到编译器有-client和-server，

具体划分应该是如下所示：

  • -client 32位client编译器
  • -server 32位server编译器
  • -d64 64位server编译器

如果你的系统是32位，那么你只能使用32位JVM，如果你是64位系统，那么可以选择32位或64位系统。

不同jvm的编译器版本如下：

jvm版本 -client -server -d64
linux 32位 32位client 32位server 出错
linux 64位 64位server 64位server 64位server
windows 32位 32位client 32位server 出错
windows 64位 64位server 64位server 64位server
macOS 64位server 64位server 64位server

我们使用的java8，默认使用的都是server编译器，同时是开启分层编译的。

默认情况JVM如何选择编译器？

假如我们没有指定编译器的参数，那么JVM是如何选择使用何种编译器的呢？

实际上jvm是考虑机器的CPU数目：

  • 在64位系统，无论机器多少CPU，都会使用server编译器
  • 在32系统
    • 如果只有一个cpu，那么使用client编译器
    • 多个cpu，使用server编译器。

如何判断当前环境jvm使用的编译器？

我们最经常使用的查看java版本命令，就可以在最后一行展示当前所使用的编译器类型：

[root@public-server9 esmp]# java -version
java version "1.8.0_172"
Java(TM) SE Runtime Environment (build 1.8.0_172-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.172-b11, mixed mode)

如上所示，Linux环境下使用的是64位server编译器。

小节：

不同的平台环境对应着不同的java版本，不同的java版本又对应着不同的编译器版本。我们在使用的时候，只需要选择对应于平台的java版本，不需要手动指定编译器，仰仗于平台所支持的编译器即可。

常规的调优可能就是选择不同的编译器版本，开放分层编译等。本章，将会具体分析除此以外的编译器优化场景。

代码缓存

JVM在编译代码后，会在代码缓存当中保存编译后的汇编语言指令集。而代码缓存的大小是固定的，换句话说，jvm能够编译的代码数量就是固定的。

前面我们提到过，如果没有被编译成汇编语言的代码，会通过解释执行的方式去运行，性能会大幅下降。所以如何控制代码缓存的大小，是一个我们可以优化的点。

代码缓存占满发生在什么情况？

通常在使用client编译器时，会占用大量的代码缓存，因为其在运行过程中需要编译的代码非常多。相反，server编译器采用优先编译的方式，运行时只会对热点代码进行编译，所以发生代码缓存占满的情况较少。综上所述，在使用分层编译的时候，也有一定的可能存在代码缓存被占满的情况。

代码缓存默认大小

代码缓存在不同版本的java当中，默认代码缓存大小也不相同，如下仅展示java7和java8的部分：

java版本 编译器类型 代码缓存大小（MB）
java7 32位 client 32
java7 32位 server 32
java7 32位 server 分层编译 48
java8 32位 client 32
java8 32位 server 分层编译 240
java8 64位 server 分层编译 240

如上可以发现，java7的代码缓存较小，比较容易出现问题。这也是为什么java7没有默认开启分层编译，而java8则默认开启。

我们可以通过下面的命令查看当前代码缓存的大小，我这里是java8：

[root@hecs-402944 opt]# jps
14186 Jps
1434 jar
655 WrapperSimpleApp
[root@hecs-402944 opt]# jinfo -flag ReservedCodeCacheSize 1434
-XX:ReservedCodeCacheSize=251658240

251658240是字节，换算后刚好240M。

如何确定正好的代码缓存？

其实这个需要根据使用情况进行实际调整，通过ReservedCodeCacheSize可以指定大小。

但是代码缓存的大小的设置要考虑到服务器实际内存的大小。如果我们将其分配过大，则这部分空间会被jvm预留出来，请确定你的服务器是否有足够大的内存。

另一个方面，32位的jvm被允许使用的最大内存为4g，其中还包括堆内存，元空间，栈，以及本地方法等等，所以代码缓存总是会被限制大小的。

在64位机器也不是越大越好，每个机器上的进程有自己的最大内存空间，超过它也是没有效果的。

综上所述，有些大型应用就需要我们对代码缓存进行调优。

如何监控代码缓存？

前面我们学习过jconsole的使用，如果你的服务允许开启jmx服务的话，那么就可以进行监控了，文章地址如下：java性能分析jconsole详解

如下图所示，就是监控代码缓存的动态图标：

我们可以根据监控的结果去调整自己服务的代码缓存大小，我这个服务举例默认的240M还有很大的差距，其实是不需要进行调优的。

到此这篇关于java性能优化之代码缓存优化的文章就介绍到这了,更多相关java 代码缓存优化内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！

赞 (0)

相关推荐

  • Java基于LoadingCache实现本地缓存的示例代码

    目录 一. 添加 maven 依赖 二.CacheBuilder 方法说明 三.创建 CacheLoader 四.工具类 五.guava Cache数据移除 一. 添加 maven 依赖 <dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>27.1-jre</version> </depend

  • Java客户端利用Jedis操作redis缓存示例代码

    前言 Redis是一个开源的Key-Value数据缓存,和Memcached类似.Redis多种类型的value,包括string(字符串).list(链表).set(集合).zset(sorted set --有序集合)和hash(哈希类型). Jedis 是 Redis 官方首选的 Java 客户端开发包.下面就来给大家详细关于Java客户端利用Jedis操作redis缓存的相关内容,话不多说,直接来看示例代码吧. 示例代码: //连接redis ,redis的默认端口是6379 Jedis

  • Java代码读取文件缓存问题解决

    Java代码读取文件缓存问题解决

    一.业务场景 最近遇到了一个Java文件读取的缓存问题,打远程断点出现的也是原来的老代码参数,好在晚上十点突然找到了解决方案,豁然开朗,现整理分享思路,希望对遇到同样文件读取缓存问题的你有帮助 我更新几次插件包后,服务器也缓存也清理了 我本地用postman调用测试,下载的文件是新文件,但是上线后发现下载下来的文件是老文件 下载下来的文件还是原来的文件,文件大小28.5K,我动态写入部分数据,按道理下载下来的文件大小应该比这个大 业务场景: 我现在需要获取一个Java项目resource目录下的

  • Java缓存池代码实例详解

    这篇实例中有四个类,分别为 CacheItem  缓存实体类 CachePool  缓存池 Student  学生实体类 MainTest  主测试类 其中,缓存实体类CacheItem  中存放管理学生实体对象Student  ,缓存实体类CacheItem  存放在缓存池CachePool  中,MainTest  主要负责整体的测试工作. 缓存实体类 package com.paic.zhangqi.cache; import java.util.Date; /** * 缓存实体 * @a

  • java中对Redis的缓存进行操作的示例代码

    Redis 是一个NoSQL数据库,也是一个高性能的key-value数据库.一般我们在做Java项目的时候,通常会了加快查询效率,减少和数据库的连接次数,我们都会在代码中加入缓存功能.Redis的高效缓存功能给我们解决了难题.下面我主要讲讲在Java项目中怎么去连接Redis服务器以及需要注意的事项. 1.导入必须的Jar包 使用Java操作Redis需要两个必须的Jar包:jedis-2.5.1.jar 和  commons-pool2-2.0.jar .每个版本可以不一样,根据你自己下载的

  • Java中LocalCache本地缓存实现代码

    前言 本次分享探讨java平台的本地缓存,是指占用JVM的heap区域来缓冲存储数据的缓存组件. 一.本地缓存应用场景 localcache有着极大的性能优势: 1. 单机情况下适当使用localcache会使应用的性能得到很大的提升. 2. 集群环境下对于敏感性要求不高的数据可以使用localcache,只配置简单的失效机制来保证数据的相对一致性. 哪些数据可以存储到本地缓存? 1．访问频繁的数据: 2．静态基础数据(长时间内不变的数据): 3．相对静态数据(短时间内不变的数据). 二.jav

  • Java本地缓存的实现代码

    使用场景 在 Java 应用中,对于访问频率高,更新少的数据,通常的方案是将这类数据加入缓存中.相对从数据库中读取来说,读缓存效率会有很大提升. 在集群环境下,常用的分布式缓存有 Redis . Memcached 等.但在某些业务场景上,可能不需要去搭建一套复杂的分布式缓存系统,在单机环境下,通常是会希望使用内部的缓存( LocalCache ). 实现 这里提供了两种 LocalCache 的实现,一种是基于 ConcurrentHashMap 实现基本本地缓存,另外一种是基于 Linked

  • java性能优化之代码缓存优化

    java性能优化之代码缓存优化

    目录 JIT编译器版本 默认情况JVM如何选择编译器? 如何判断当前环境jvm使用的编译器? 代码缓存 代码缓存占满发生在什么情况? 代码缓存默认大小 如何确定正好的代码缓存? 如何监控代码缓存? JIT编译器版本 JIT编译器有不同的版本,而最终你使用哪种,取决于你所使用的系统平台.前面的文章我们说到编译器有-client和-server, 具体划分应该是如下所示: -client 32位client编译器 -server 32位server编译器 -d64 64位server编译器 如果你的

  • MySQL优化之缓存优化（续）

    MySQL 内部处处皆缓存,等什么时候看了MySQL的源码,再来详细的分析缓存的是如何利用的.这部分主要将各种显式的缓存优化: 查询缓存优化 结果集缓存 排序缓存 join 连接缓存 表缓存Cache 与表结构定义缓存Cache 表扫描缓存buffer MyISAM索引缓存buffer 日志缓存 预读机制 延迟表与临时表 1.查询缓存优化 查询缓存不仅将查询语句结构缓存起来,还将查询结果缓存起来.一段时间内,如果是同样的SQL,则直接从缓存中读取结果,提高查找数据的效率.但当缓存中的数据与硬盘中

  • Java性能优化之数据结构实例代码

    Java性能优化之数据结构实例代码

    -举例(学生排课)- 正常思路的处理方法和优化过后的处理方法: 比如说给学生排课.学生和课程是一个多对多的关系. 按照正常的逻辑 应该有一个关联表来维护 两者之间的关系. 现在,添加一个约束条件用于校验.如:张三上学期学过的课程,在排课的时候不应该再排这种课程. 所以需要出现一个约束表(即:历史成绩表). 即:学生选课表,需要学生成绩表作为约束. -方案一:正常处理方式- 当一个学生进行再次选课的时候.需要查询学生选课表看是否已经存在. 即有如下校验: //查询 学生code和课程code分别为

  • 10种简单的Java性能优化

    10种简单的Java性能优化

    最近"全网域(Web Scale)"一词被炒得火热,人们也正在通过扩展他们的应用程序架构来使他们的系统变得更加"全网域".但是究竟什么是全网域?或者说如何确保全网域? 扩展的不同方面 全网域被炒作的最多的是扩展负载(Scaling load),比如支持单个用户访问的系统也可以支持10 个.100个.甚至100万个用户访问.在理想情况下,我们的系统应该保持尽可能的"无状态化(stateless)".即使必须存在状态,也可以在网络的不同处理终端上转化

  • 详解Java代码常见优化方案

    首先,良好的编码规范非常重要.在 java 程序中,访问速度.资源紧张等问题的大部分原因,都是代码不规范造成的. 单例的使用场景 单例模式对于减少资源占用.提高访问速度等方面有很多好处,但并不是所有场景都适用于单例. 简单来说,单例主要适用于以下三个方面: 多线程场景,通过线程同步来控制资源的并发访问. 多线程场景,控制数据共享,让多个不相关的进程或线程之间实现通信(通过访问同一资源来控制). 控制实例的产生,单例只实例化一次,以达到节约资源的目的: 不可随意使用静态变量 当某个对象被定义为 s

  • Java性能优化技巧汇总

    本文实例汇总了Java性能优化技巧.分享给大家供大家参考.具体分析如下: 这里参考了些书籍,网络资源整理出来,适合于大多数Java应用 在JAVA程序中,性能问题的大部分原因并不在于JAVA语言,而是程序本身.养成良好的编码习惯非常重要,能够显著地提升程序性能. 1.尽量使用final修饰符. 带有final修饰符的类是不可派生的.在JAVA核心API中,有许多应用final的例子,例如java.lang.String.为String类指定final防止了使用者覆盖length()方法.另外,如

  • java代码效率优化方法(推荐)

    1. 尽量指定类的final修饰符 带有final修饰符的类是不可派生的. 如果指定一个类为final,则该类所有的方法都是final.Java编译器会寻找机会内联(inline)所有的 final方法(这和具体的编译器实现有关).此举能够使性能平均提高50% . 2. 尽量重用对象. 特别是String 对象的使用中,出现字符串连接情况时应用StringBuffer 代替.由于系统不仅要花时间生成对象,以后可能还需花时间对这些对象进行垃圾回收和处理.因此,生成过多的对象将会给程序的性能带来很大

  • java性能优化之编译器版本与平台对应关系

    目录 JIT编译器版本 默认情况JVM如何选择编译器? 如何判断当前环境jvm使用的编译器? 小节 本章节更加具体化的学习编译器还有哪些可以优化的方便,让你的应用展现出更好的性能. JIT编译器版本 JIT编译器有不同的版本,而最终你使用哪种,取决于你所使用的系统平台.前面的文章我们说到编译器有-client和-server,具体划分应该是如下所示: -client 32位client编译器 -server 32位server编译器 -d64 64位server编译器 如果你的系统是32位,那么

  • java性能优化四种常见垃圾收集器汇总

    目录 前言 常见的垃圾回收器和算法 serial 串行垃圾收集器 Parallel 多线程垃圾收集器 CMS 收集器 G1 收集器 显式垃圾收集 前言 本篇文章我们来具体看看如何选择合适的垃圾收集器.每种垃圾收集器都有其不同的算法实现和步骤,下面我们简单描述下我们常见的四种垃圾收集器的算法过程,感兴趣的同学们最好先看下以下的两篇文章去增加理解.分别介绍了一些垃圾回收的基本概念,和各种垃圾回收器回收的过程,内容重复,本章不会在去单独讲解一遍.所以本章做一些归纳总结. JVM GC 垃圾收集梳理总结

  • Android性能优化之ViewPagers + Fragment缓存优化

    Android性能优化之ViewPagers + Fragment缓存优化

    目录 前言 1 ViewPager懒加载优化 1.1 ViewPager的缓存机制 1.2 ViewPager懒加载方案 2 ViewPager2与ViewPager的区别 前言 大家看标题,可能会有点儿懵,什么是ViewPagers,因为在很久之前,我们使用的都是ViewPager,但是现在更多的是在用ViewPager2,因此用ViewPagers(ViewPager.ViewPager2)来代替两者,主要介绍两者的区别. ViewPagers嵌套Fragment架构,在我们常用的App中随

随机推荐