Memory Analyzer

告警 正在开会，突然钉钉告警声响个不停，同时市场人员反馈客户在投诉系统登不进了，报504错误。查看钉钉上的告警信息，几台业务服务器节点全部报CPU超过告警阈值，达100%。 赶紧从会上下来，SSH登录服务器，使用 top 命令查看，几个Java进程CPU占用达到180%，190%，这几个Java进程对应同一个业务服务的几个Pod（或容器）。 定位 使用 docker stats 命令查看本节点容器资源使用情况，对占用CPU很高的容器使用 docker exec -it <容器ID>bash 进入。 在容器内部执行 top 命令查看，定位到占用CPU高的进程ID，使用 top -Hp <进程ID> 定位到占用CPU高的线程ID。 使用 jstack <进程ID> > jstack.txt 将进程的线程栈打印输出。 退出容器， 使用 docker cp <容器ID>:/usr/local/tomcat/jstack.txt ./ 命令将jstack文件复制到宿主机，便于查看。获取到jstack信息后，赶紧重启服务让服务恢复可用。 5.将2中占用CPU高的线程ID使用 pringf '%x\n' <线程ID> 命令将线程ID转换为十六进制形式。假设线程ID为133，则得到十六进制85。在jstack.txt文件中定位到 nid=0x85的位置，该位置即为占用CPU高线程的执行栈信息

告警 正在开会，突然钉钉告警声响个不停，同时市场人员反馈客户在投诉系统登不进了，报504错误。查看钉钉上的告警信息，几台业务服务器节点全部报CPU超过告警阈值，达100%。 赶紧从会上下来，SSH登录服务器，使用 top 命令查看，几个Java进程CPU占用达到180%，190%，这几个Java进程对应同一个业务服务的几个Pod（或容器）。 定位 使用 docker stats 命令查看本节点容器资源使用情况，对占用CPU很高的容器使用 docker exec -it <容器ID>bash 进入。 在容器内部执行 top 命令查看，定位到占用CPU高的进程ID，使用 top -Hp <进程ID> 定位到占用CPU高的线程ID。 使用 jstack <进程ID> > jstack.txt 将进程的线程栈打印输出。 退出容器， 使用 docker cp <容器ID>:/usr/local/tomcat/jstack.txt ./ 命令将jstack文件复制到宿主机，便于查看。获取到jstack信息后，赶紧重启服务让服务恢复可用。 5.将2中占用CPU高的线程ID使用 pringf '%x\n' <线程ID> 命令将线程ID转换为十六进制形式。假设线程ID为133，则得到十六进制85。在jstack.txt文件中定位到 nid=0x85的位置，该位置即为占用CPU高线程的执行栈信息

告警 正在开会，突然钉钉告警声响个不停，同时市场人员反馈客户在投诉系统登不进了，报504错误。查看钉钉上的告警信息，几台业务服务器节点全部报CPU超过告警阈值，达100%。 赶紧从会上下来，SSH登录服务器，使用 top 命令查看，几个Java进程CPU占用达到180%，190%，这几个Java进程对应同一个业务服务的几个Pod（或容器）。 定位 使用 docker stats 命令查看本节点容器资源使用情况，对占用CPU很高的容器使用 docker exec -it <容器ID> bash 进入。 在容器内部执行 top 命令查看，定位到占用CPU高的进程ID，使用 top -Hp <进程ID> 定位到占用CPU高的线程ID。 使用 jstack <进程ID> > jstack.txt 将进程的线程栈打印输出。 退出容器， 使用 docker cp <容器ID>:/usr/local/tomcat/jstack.txt ./ 命令将jstack文件复制到宿主机，便于查看。获取到jstack信息后，赶紧重启服务让服务恢复可用。 将2中占用CPU高的线程ID使用 pringf '%x\n' <线程ID> 命令将线程ID转换为十六进制形式。假设线程ID为133，则得到十六进制85。在jstack.txt文件中定位到 nid=0x85 的位置，该位置即为占用CPU高线程的执行栈信息

告警 正在开会，突然钉钉告警声响个不停，同时市场人员反馈客户在投诉系统登不进了，报504错误。查看钉钉上的告警信息，几台业务服务器节点全部报CPU超过告警阈值，达100%。 赶紧从会上下来，SSH登录服务器，使用 top 命令查看，几个Java进程CPU占用达到180%，190%，这几个Java进程对应同一个业务服务的几个Pod（或容器）。 定位 使用 docker stats 命令查看本节点容器资源使用情况，对占用CPU很高的容器使用 docker exec -it <容器ID> bash 进入。 在容器内部执行 top 命令查看，定位到占用CPU高的进程ID，使用 top -Hp <进程ID> 定位到占用CPU高的线程ID。 使用 jstack <进程ID> > jstack.txt 将进程的线程栈打印输出。 退出容器， 使用 docker cp <容器ID>:/usr/local/tomcat/jstack.txt ./ 命令将jstack文件复制到宿主机，便于查看。获取到jstack信息后，赶紧重启服务让服务恢复可用。 将2中占用CPU高的线程ID使用 pringf '%x\n' <线程ID> 命令将线程ID转换为十六进制形式。假设线程ID为133，则得到十六进制85。在jstack.txt文件中定位到 nid=0x85 的位置，该位置即为占用CPU高线程的执行栈信息

1、 Java语言有哪些特点 （1）简单易学、有丰富的类库 （2）面向对象（Java最重要的特性，让程序耦合度更低，内聚性更高） （3）与平台无关性（JVM是Java跨平台使用的根本） （4）可靠安全 （5）支持多线程 2、面向对象和面向过程的区别 面向过程：是分析解决问题的步骤，然后用函数把这些步骤一步一步地实现，然后在使用的时候一一调用则可。性能较高，所以单片机、嵌入式开发等一般采用面向过程开发 面向对象：是把构成问题的事务分解成各个对象，而建立对象的目的也不是为了完成一个个步骤，而是为了描述某个事物在解决整个问题的过程中所发生的行为。面向对象有封装、继承、多态的特性，所以易维护、易复用、易扩展。可以设计出低耦合的系统。但是性能上来说，比面向过程要低。 3 、八种基本数据类型的大小，以及他们的封装类基本类型 大小（字节） 默认值 封装类 注： 1.int是基本数据类型 ，Integer是int的封装类，是引用类型。int默认值是0，而Integer默认值是null，所以Integer能区分出0和null的情况。一旦java看到null，就知道这个引用还没有指向某个对象， 2.基本数据类型在声明时系统会自动给它分配空间 ，而引用类型声明时只是分配了引用空间，必须通过实例化开辟数据空间之后才可以赋值。数组对象也是一个引用对象，将一个数组赋值给另一个数组时只是复制了一个引用

状况描述： 最近项目新打的版本，过不了多长时间，项目就会挂掉。状况就是处于一种假死的状态。索引查询都很慢，几乎进行不了任何操作，慢慢卡死。 然后我们再发版时，只能基于之前打好的war包，替换或者增加class文件。 情况对比及分析： 由于之前代码做过一次大整顿，提交的代码比较多，所以通过回滚版本的方式解决，比较困难。一是因为整顿的成果不能白白抹杀；二是那么多文件，靠人工挨个对比查找，比较困难。 解决方案一： 之前， 一直对目前项目的打包方式心存质疑，所以这次发生问题时，我首先怀疑的对象是Jenkins和生产的Tomcat服务器。我通过堡垒机连接到生产时，发现通过Jenkins启动应用程序，会启动两个两个tomcat进程。 然后，这似乎更加坚定了我的看法，马上就找到了运维，但是经确认后，是没有问题的。一个是用root用户启动的，一个是用tomcat用户启动的。一个守护进程，一个应用进程。 解决方案二： 排除了服务器的问题，开始正面考虑程序的问题。 重新发项目有问题的版本，Dump下来的日志，然后迅速回滚观察。单台机器的dump日志有5个G： 通过Memory Analyzer分析，在Leak Supects Report 视图中，有如下分析结果： 上图所示，共有三类问题a、b、c；还有一些其他的，类型为d。 先来看第一个问题（后来发现，前几个问题都是同一个问题）

1、 Java语言有哪些特点 （1）简单易学、有丰富的类库 （2）面向对象（Java最重要的特性，让程序耦合度更低，内聚性更高） （3）与平台无关性（JVM是Java跨平台使用的根本） （4）可靠安全 （5）支持多线程 2、面向对象和面向过程的区别 面向过程：是分析解决问题的步骤，然后用函数把这些步骤一步一步地实现，然后在使用的时候一一调用则可。性能较高，所以单片机、嵌入式开发等一般采用面向过程开发 面向对象：是把构成问题的事务分解成各个对象，而建立对象的目的也不是为了完成一个个步骤，而是为了描述某个事物在解决整个问题的过程中所发生的行为。面向对象有封装、继承、多态的特性，所以易维护、易复用、易扩展。可以设计出低耦合的系统。但是性能上来说，比面向过程要低。 3 、八种基本数据类型的大小，以及他们的封装类基本类型 大小（字节） 默认值 封装类 注： 1.int是基本数据类型 ，Integer是int的封装类，是引用类型。int默认值是0，而Integer默认值是null，所以Integer能区分出0和null的情况。一旦java看到null，就知道这个引用还没有指向某个对象， 2.基本数据类型在声明时系统会自动给它分配空间 ，而引用类型声明时只是分配了引用空间，必须通过实例化开辟数据空间之后才可以赋值。数组对象也是一个引用对象，将一个数组赋值给另一个数组时只是复制了一个引用

上一篇我们讲了java的引用机制，今天我们来一下和它有关的app性能优化(其实也不是很大)。 性能优化的目标 在网上也看到过很多相关的文章，他们基本总结为：快,稳,省,小,描述的很准确.如下图 (注：此图不知道啥时候收集的，如有侵权，立删)： 快 如何让app在运行过程过不卡顿，运行流畅，速度快,也就是说如何解决卡顿呢？我们先看看那些因素影响卡顿？ 1. UI,包括ui的绘制,刷新等 2. 启动,包括冷启动,热启动,温启动等 3. 跳转,页面跳转,前后天切换 4. 及时反馈，点击事件,滑动,系统事件 UI 这个涉及到android的系统显示原理，我们简单了解一下： Android 显示过程可以简单概括为：Android 应用程序把经过测量,布局、绘制后的 surface 缓存数据，通过 SurfaceFlinger 把数据渲染到显示屏幕上， 通过 Android 的刷新机制来刷新数据。也就是说应用层负责绘制，系统层负责渲染，通过进程间通信把应用层需要绘制的数据传递到系统层服务，系统层服务通过刷新机制把数据更新到屏幕上。 换一种方式说：Android 系统每隔 16ms 发出 VSYNC 信号，触发对 UI 进行渲染，如果每次渲染都成功，这样就能够达到流畅的画面所需的 60FPS。（注：FPS 表示每秒传递的帧数。）在理想情况下，60 FPS 就感觉不到卡

一.何为App的性能 拿小车举例，大家知道什么是一辆小车的性能吗？同学甲说，是否省油、加速是否够快、开起来是否稳定、安全等等。 没错，那就是小车的性能。 那App的性能又是指什么呢？同学乙说，App启动是否够快，运行是否流畅，是否省电、省流量，安装包体积是否够小等等。 是的，这就是App的性能。 二.关注App性能，有什么用 我们知道，一辆小车性能越好，加速越快，跑的越稳，越省油。 App也一样，性能越好，运行更流畅、更稳定、更省流量、电量，包的体积也会更小，这能给用户带来优秀的体验，进而也会提升App的知名度。 既然App性能那么重要，那我们就要掌握App性能优化的技能了。 三.如何进行App性能优化 掌握App性能优化，是Android开发人员进阶中高级的必备技能。那如何进行App的性能优化呢？ 我们可以从这几个方面入手：卡顿优化、内存优化、稳定性优化、耗电优化、安装包大小优化、数据库SQLite优化、网络优化。 接下来，我们逐一展开讲解。 1.卡顿优化 1.1卡顿场景 可分为四个大的方向： 1.1.1UI UI包括绘制和渲染。 1.1.2启动 启动可分为冷启动、热启动。 1.1.3跳转 跳转包括页面间跳转和前后台切换。 1.1.4响应 包括：点击、滑动、系统事件、按键。 1.2卡顿原因 可分为以下两方面原因： 1.2.1绘制任务太重 首先，我们要明白这样一个概念

说下对象的创建方法？对象的内存布局？对象的访问定位？ 四种不同的方法创建对象 1、用new语句创建对象，这是最常用的创建对象的方式； 2、调用对象的clone方法。 　　MyObject obj =new MyObject(); 　　MyObject objs= obj.clone(); 使用clone方法克隆一个对象的步骤： 　　1）被克隆的类要实现Cloneable接口； 　　2）被克隆的类要重写clone方法； 1 class Obj implements Cloneable{ 2 private Date birth = new Date(); 3 public Date getBirth(){ 4 return birth; 5 } 6 public void setBirth(){ 7 this .birth= birth; 8 } 9 public void changeDate(){ 10 this .birth.setMonth(4 ); 11 } 12 public Object clone(){ 13 Obj o = null ; // o指向了复制后的新对象 14 try { 15 o=(Obj) super .clone(); // 实现浅复制 16 } catch (CloneNotSupportedException e){ 17 e