一.查看步骤 cmd执行命令: java -XX:+PrintCommandLineFlags -version 输出如下(举例): 针对上述的-XX:UseParallelGC,这边我们引用<深入理解Java虚拟机:JVM高级特性与最佳实践>的介绍: 也就是说,打开此开关,使用的垃圾收集器是:新生代(Parallel Scavenge),老年代(Ps MarkSweep)组合. 二.验证下,是不是那么回事吧 我用ide起了一个程序,然后在main中进行长时间睡眠.启动时,设置其VM 参数如下

redis默认是不能远程访问的,如果希望多台机子共用redis数据库,那就需要开启redis远程连接访问.既然可以远程连接了,那就需要密码登陆,否则不安全.下面是具体的方法,按照步骤一步一步来就OK了 下面代码的运行环境为 centos 7 redis 3.2.9 一.配置安装目录下的redis.conf文件 bind 0.0.0.0 修改为这个 port 6379 这个为redis端口 #修改这个为yes,以守护进程的方式运行,就是关闭了远程连接窗口,redis依然运行 daemonize y

Docker CentOS / Ubuntu容器开启 SSH 服务 在CentOS容器内执行 yum install passwd openssl openssh-server -y # Ubuntu把yum改成apt-get ssh-keygen -q -t rsa -b 2048 -f /etc/ssh/ssh_host_rsa_key -N '' ssh-keygen -q -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key -N '' ssh-keygen -

1.设置libvirtd 编辑/etc/libvirt/libvirtd.conf listen_tls = 0 listen_tcp = 1 auth_tcp="none" tcp_port = "16509" 2.设置服务为监听状态 即使设置了listen_tcp也不会开启监听服务, 重启libvirt-bin服务,验证: sudo netstat -nlpt # 可见16509端口并没有开启 ps aux | grep libvirt # 可见libvirtd

转自:https://www.zybuluo.com/jewes/note/57352 选项的分类 Hotspot JVM提供以下三大类选项: 1. 标准选项:这类选项的功能是很稳定的,在后续版本中也不太会发生变化.运行java或者java -help可以看到所有的标准选项.所有的标准选项都是以-开头,比如-version, -server等. 2. X选项:比如-Xms.这类选项都是以-X开头,可能由于这个原因它们被称为X选项.运行java -X命令可以看到所有的X选项.这类选项的功能还是很稳

我们以Sun HotSpot VM来进行分析,首先应该知道,如果我们没有指定任何GC策略的时候,JVM默认使用的GC策略.Java虚拟机是按照分代的方式来回收垃圾空间,我们应该知道,垃圾回收主要是针对堆(Heap)内存进行分代回收,将对内存可以分成新生代(Young Generation).年老代(Tenured Generation)和永久代(Permanent Generation)三个部分. 分代GC 分代GC包括如下三代: 新生代(Young Generation) 新生代有划分为Ede

一.概述 垃圾收集 Garbage Collection 通常被称为“GC”,它诞生于1960年 MIT 的 Lisp 语言,经过半个多世纪,目前已经十分成熟了. jvm 中,程序计数器.虚拟机栈.本地方法栈都是随线程而生随线程而灭,栈帧随着方法的进入和退出做入栈和出栈操作,实现了自动的内存清理,因此,我们的内存垃圾回收主要集中于 java 堆和方法区中,在程序运行期间,这部分内存的分配和使用都是动态的. 二.对象存活判断 判断对象是否存活一般有两种方式: 引用计数:每个对象有一个引用计数属性,

参考文章: 并发编程网:http://ifeve.com/useful-jvm-flags-part-4-heap-tuning/ 一.参数分类 HotSpot JVM 提供了三类参数. 第一类包括了标准参数.顾名思义,标准参数中包括功能和输出的参数都是很稳定的,很可能在将来的 JVM 版本中不会改变.你可以用 java 命令(或者是用 java -help)检索出所有标准参数.我们在第一部分中已经见到过一些标准参数,例如:-server. 第二类是 X 参数,非标准化的参数在将来的版本中可能会

垃圾收集器与内存分配策略 前言:本文基于<深入java虚拟机>再加上个人的理解以及其他相关资料,对内容进行整理浓缩总结.本文中的图来自网络,感谢图的作者.如果有不正确的地方,欢迎指出. 目录 jvm系列(一):jvm内存区域与溢出 jvm系列(二):垃圾收集器与内存分配策略 回顾 上文介绍了jvm的内存区域以及介绍了内存的溢出情况. jvm区域分为5个,线程独有:虚拟机栈,本地方法栈,程序计数器.线程共享:方法区,堆 两种溢出:栈溢出(StackOverflowError),OutOfMemo

jdk6和7服务器端(-server) 默认的新生代的垃圾回收器为:PS Scavenge,老年代默认的垃圾回收器为:PS MarkSweep 目前项目使用了jdk7,tomcat7,经常出现内存堆使用量200s持续超过堆总内存80%,触发报警. 由于项目最近的更新为jdk和tomcat升级,从6升级到7,而之前使用tomcat6时并未报警,是因为tomcat的一个监听器行为模式变更造成的 <Listener className="org.apache.catalina.core.JreM

垃圾收集算法 标记-清除算法 最基础的收集算法是"标记-清除"(Mark-Sweep)算法,分两个阶段:首先标记出所有需要回收的对象,在标记完成后统一回收所有被标记的对象. 不足:一个是效率问题,标记和清除两个过程的效率都不高:另一个是空间问题,标记清除之后会产生大量不连续的内存碎片,空间碎片太多可能导致以后在程序运行过程需要分配较大对象时,无法找到足够的连续内存而不得不提前触发另一个的垃圾收集动作. 复制算法 为了解决效率问题,一种称为复制(Copying)的收集算法出现了,它将可用

1.1   垃圾收集器 垃圾收集器是内存回收的具体实现.以下讨论的收集器是基于JDK1.7Update14之后的HotSpot虚拟机.这个虚拟机包含的所有收集器有: 上图展示了7种作用于不同分代的收集器,如果两个收集器之间存在连线,就说明它们可以搭配使用.虚拟机所处的区域,则表示它是属于新生代收集器还是老年代收集器.接下来笔者将逐一介绍这些收集器的特性.基本原理和使用场景,并重点分析CMS和G1这两款相对复杂的收集器,了解它们的部分运作细节. 直到现在为止还没有最好的收集器出现,更加没有万能的收

JVM 在程序执行的过程中, 提供了GC行为的原生数据.那么, 我们就可以利用这些原生数据来生成各种报告.原生数据(raw data) 包括: 各个内存池的当前使用情况, 各个内存池的总容量, 每次GC暂停的持续时间, GC暂停在各个阶段的持续时间. 可以通过这些数据算出各种指标, 例如: 程序的内存分配率, 提升率等等.本章主要介绍如何获取原生数据. 后续的章节将对重要的派生指标(derived metrics)展开讨论, 并引入GC性能相关的话题. JMX API 从 JVM 运行时获取GC

Java与C++之间有一堵由内存动态分配和垃圾收集技术所围成的“高墙”,墙外面的人想进去,墙里面的人却想出来. 3.1 概述 说起垃圾收集(Garbage Collection,GC),大部分人都把这项技术当做Java语言的伴生产物.事实上,GC的历史比Java久远,1960年诞生于MIT的Lisp是第一门真正使用内存动态分配和垃圾收集技术的语言.当Lisp还在胚胎时期时,人们就在思考GC需要完成的3件事情: 哪些内存需要回收? 什么时候回收? 如何回收? 经过半个多世纪的发展,目前内存的动态分

1.概述 如果说收集算法是内存回收的方法论,那么垃圾收集器就是内存回收的具体实现.Java虚拟机规范中对垃圾收集器应该如何实现并没有规定,因此不同的厂商.不同版本的虚拟机所提供的垃圾收集器都可能会有很大差别,并且一般都会提供参数供用户根据自己的应用特点和要求组合出各个年代所使用的收集器.这里讨论的收集器基于JDK 1.7 Update 14之后的HotSpot虚拟机(在这个版本中正式提供了商用的G1收集器,之前G1仍处于实验状态). 1.1 垃圾收集器组合 这个虚拟机包含的所有收集器如图所示:

本文主要是对<深入理解java虚拟机 第二版>第三章部分做的总结,文章中大部分内容都来自这章内容,也是博客 JVM 学习的第二部分. 简述 说到垃圾收集(Garbage Collection,GC),很多人可能会认为这是 Java 自有的特性,曾经我也一度这样想,后来才知道 GC 的历史要远远长于 Java,它第一次真正使用是在 Lisp 中,现在,像 python.go 等都有自己的垃圾收集器.在 GC 最开始设计时,人们在思考 GC 时就需要完成三件事情: 哪些内存需要进行回收? 什么时候

备注:本文引自<深入理解Java虚拟机第二版>仅供参考 图片来自:http://csdn.net/WSYW126 垃圾收集器与内存分配策略 概述 GC要完成3件事: 哪些内存需要回收? 什么时候回收? 如何回收? Java内存运行时区域的各部分,其中程序计数器.虚拟机栈.本地方法栈3个区域随线程而生,随线程而灭:栈中的栈帧随着方法的进入和退出而有条不紊地执行着入栈和出栈操作.每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的,因此这几个区域的内存分配和回收都具备确定性,在这几个区域内就

在测试服务器上使用如下命令可以查看当前使用的 GC收集器,当然不止这一个命令可以看到,还有其他一些方式 第三列”=”表示第四列是参数的默认值,而”:=” 表明了参数被用户或者JVM赋值了 [csii@devpwcoreapp bin]$ ./java -XX:+PrintFlagsFinal -version | grep : uintx InitialHeapSize := {product} uintx MaxHeapSize := {product} uintx ParallelGCThr

摘要: 线上系统为何经常出错?数据库为何屡遭黑手?业务调用为何频频失败?连环异常堆栈案,究竟是那次调用所为? 数百台服务器意外雪崩背后又隐藏着什么?是软件的扭曲还是硬件的沦丧? 走进科学带你了解Greys, Java线上问题诊断工具. 线上系统为何经常出错?数据库为何屡遭黑手?业务调用为何频频失败?连环异常堆栈案,究竟是那次调用所为?数百台服务器意外雪崩背后又隐藏着什么?是软件的扭曲还是硬件的沦丧?走进科学带你了解Greys, Java线上问题诊断工具. Greys的诞生 很早的时候,我们使用B

CrossAnalyzer-调用链分析 在分布式环境中,应用是运行在独立的进程中的,有可能是不同的机器,或者不同的服务器进程.那么他们如果想要彼此联系在一起,形成一个调用链,在Cat中,CrossAnalyzer会统计不同服务之间调用的情况,包括服务的访问量,错误量,响应时间,QPS等,这里的服务主要指的是 RPC 服务,在微服务监控中,这是核心. 在讲 CrossAnalyzer 的处理逻辑之前,我们先看下客户端的埋点的一个模拟情况. 一般情况下不同服务会通过几个ID进行串联.这种串联的模式,

转载:https://wangkang007.gitbooks.io/jvm/content/la_ji_shou_ji_qi.html 收集器 1.1 Serial(串行)收集器 Serial收集器是一个新生代收集器(Serial Old对应老年代),单线程执行,使用复制算法.它在进行垃圾收集时,必须暂停其他所有的工作线程(用户线程)也就是传说中的Stop The World.是Jvm client模式下默认的新生代收集器.对于限定单个CPU的环境来说,Serial收集器由于没有线程交互的开销