转载:http://blog.csdn.net/kimylrong/article/details/50970493 查询.监控.分析Java应用程序的时候,我们关注的点主要集中在资源利用,比如CPU,内存,IO,线程等.其中内存以及线程的分析尤为常见.内存,是否有内存泄漏,各个区块内存分配是否大小合适.线程,数目是否合理,有没有死锁,运行状态如何. jps -vl jps是JDK提供的一个小工具,上面的命令会把操作系统里面的java应用都展示出来,显示PID,启动类或者JAR,VM参数.可以通

一.介绍 jstack是java虚拟机自带的一种堆栈跟踪工具.jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息,如果是在64位机器上,需要指定选项"-J-d64",Windows的jstack使用方式只支持以下的这种方式: 命令格式 jstack [-l] pid 主要分为两个功能: a．  针对活着的进程做本地的或远程的线程dump: b．  针对core文件做线程dump. jstack用于生成java虚拟机当前时刻的线程快照.线程快

这个讲的好系列:  如何使用jstack分析线程状态 转:http://www.jianshu.com/p/6690f7e92f27 背景 记得前段时间,同事说他们测试环境的服务器cpu使用率一直处于100%,本地又没有什么接口调用,为什么会这样?cpu使用率居高不下,自然是有某些线程一直占用着cpu资源,那又如何查看占用cpu较高的线程? 当然一个正常的程序员不会写出上述代码,这里只是为了让一个线程占用较高的cpu资源. top命令 在linux环境下,可以通过top命令查看各个进程的cpu使

背景 记得前段时间,同事说他们测试环境的服务器cpu使用率一直处于100%,本地又没有什么接口调用,为什么会这样?cpu使用率居高不下,自然是有某些线程一直占用着cpu资源,那又如何查看占用cpu较高的线程?   当然一个正常的程序员不会写出上述代码,这里只是为了让一个线程占用较高的cpu资源. top命令 在linux环境下,可以通过top命令查看各个进程的cpu使用情况,默认按cpu使用率排序   1.上图中可以看出pid为23344的java进程占用了较多的cpu资源:2.通过top -H

英文原文:JVM: How to analyze Thread Dump 在这篇文章里我将教会你如何分析JVM的线程堆栈以及如何从堆栈信息中找出问题的根因.在我看来线程堆栈分析技术是Java EE产品支持工程师所必须掌握的一门技术.在线程堆栈中存储的信息,通常远超出你的想象,我们可以在工作中善加利用这些信息. 我的目标是分享我过去十几年来在线程分析中积累的知识和经验.这些知识和经验是在各种版本的JVM以及各厂商的JVM供应商的深入分析中获得的,在这个过程中我也总结出大量的通用问题模板. 那么,准

一.介绍 jstack是java虚拟机自带的一种堆栈跟踪工具.jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息,如果是在64位机器上,需要指定选项"-J-d64",Windows的jstack使用方式只支持以下的这种方式: jstack [-l] pid 主要分为两个功能: a．  针对活着的进程做本地的或远程的线程dump: b．  针对core文件做线程dump. jstack用于生成java虚拟机当前时刻的线程快照.线程快照是当前j

Elasticsearch源码分析—线程池(十一) 转自:https://www.felayman.com/articles/2017/11/10/1510291570687.html 线程池 每个节点都有一些线程池来优化线程内存的消耗,按节点来配置管理.有些线程池还拥有与之关联的队列配置,用来允许挂住一些未处理的请求,而不是丢弃它. Elasticsearch对线程池的处理的源码在org.elasticsearch.node.Node中,核心代码为: final ThreadPool thre

flask之分析线程和协程 01 思考:每个请求之间的关系 我们每一个请求进来的时候都开一个进程肯定不合理,那么如果每一个请求进来都是串行的,那么根本实现不了并发,所以我们假定每一个请求进来使用的是线程. 那么线程中数据互相不隔离,存在修改数据的时候数据不安全的问题. 假定我们的需求是,每个线程都要设置值,并且该线程打印该线程修改的值. from threading import Thread,current_thread import time class Foo(object): def _

JUC源码分析-线程池篇(三)ScheduledThreadPoolExecutor ScheduledThreadPoolExecutor 继承自 ThreadPoolExecutor.它主要用来在给定的延迟之后运行任务,或者定期执行任务.ScheduledThreadPoolExecutor 的功能与 Timer 类似,但 Timer 对应的是单个后台线程,而 ScheduledThreadPoolExecutor 可以在构造函数中指定多个对应的后台线程数. JUC源码分析-线程池篇(三)T

JUC源码分析-线程池篇(二)FutureTask JDK5 之后提供了 Callable 和 Future 接口,通过它们就可以在任务执行完毕之后得到任务的执行结果.本文从源代码角度分析下具体的实现原理. 1. 接口介绍 1.1 Callable 接口 对于需要执行的任务需要实现 Callable 接口,Callable 接口定义如下: public interface Callable<V> { V call() throws Exception; } 可以看到 Callable 是个泛型

JUC源码分析-线程池篇(三)Timer Timer 是 java.util 包提供的一个定时任务调度器,在主线程之外起一个单独的线程执行指定的计划任务,可以指定执行一次或者反复执行多次. 1. Timer 类结构 Timer 由 TimerThread,TaskQueue ,TimerTask 组成. Timer 初始化时会构建一个 TimerThread 线程用于执行调度任务.TaskQueue 保存所有调度的定时任务,基于二叉树小顶堆时间,第一个要执行的任务永远位于 queue[1],其插

JUC源码分析-线程池篇(一):ThreadPoolExecutor Java 中的线程池是运用场景最多的并发框架,几乎所有需要异步或并发执行任务的程序都可以使用线程池.在开发过程中,合理地使用线程池能够带来 3 个好处. 第一:降低资源消耗.通过重复利用已创建的线程降低线程创建和销毁造成的消耗. 第二:提高响应速度.当任务到达时,任务可以不需要等到线程创建就能立即执行. 第三:提高线程的可管理性.线程是稀缺资源,如果无限制地创建,不仅会消耗系统资源,还会降低系统的稳定性,使用线程池可以进行统一

nginx源码分析线程池详解 一.前言     nginx是采用多进程模型,master和worker之间主要通过pipe管道的方式进行通信,多进程的优势就在于各个进程互不影响.但是经常会有人问道,nginx为什么不采用多线程模型(这个除了之前一篇文章讲到的情况,别的只有去问作者了,HAHA).其实,nginx代码中提供了一个thread_pool(线程池)的核心模块来处理多任务的.下面就本人对该thread_pool这个模块的理解来跟大家做些分享(文中错误.不足还请大家指出,谢谢) 二.thr

目录 flask之分析线程和协程 01 思考:每个请求之间的关系 02 threading.local 03 通过字典自定义threading.local 04 通过setattr和getattr实现自定义threthreading.local 05 每个对象有自己的存储空间(字典) 06 如果是你会如何设计flask的请求并发? flask之分析线程和协程 01 思考:每个请求之间的关系 我们每一个请求进来的时候都开一个进程肯定不合理,那么如果每一个请求进来都是串行的,那么根本实现不了并发,所

百篇博客系列篇.本篇为: v21.xx 鸿蒙内核源码分析(线程概念篇) | 是谁在不断的折腾CPU | 51.c.h .o 任务管理相关篇为: v03.xx 鸿蒙内核源码分析(时钟任务篇) | 触发调度谁的贡献最大 | 51.c.h .o v04.xx 鸿蒙内核源码分析(任务调度篇) | 任务是内核调度的单元 | 51.c.h .o v05.xx 鸿蒙内核源码分析(任务管理篇) | 任务池是如何管理的 | 51.c.h .o v06.xx 鸿蒙内核源码分析(调度队列篇) | 内核有多少个调度队列

周末看到一个用jstack查看死锁的例子.昨天晚上总结了一下jstack(查看线程).jmap(查看内存)和jstat(性能分析)命令. 1.1．Jstack 1.1   jstack能得到运行java程序的java stack和native stack的信息.可以轻松得知当前线程的运行情况.如下图所示  注:这个和thread dump是同样的结果.但是thread dump是用kill -3 pid命令,还是服务器上面少用kill为妙 1.2   命名行格式 jstack [ option

前面一篇文章从Executors中的工厂方法入手,已经对ThreadPoolExecutor的构造和使用做了一些整理.而这篇文章,我们将接着前面的介绍,从源码实现上对ThreadPoolExecutor在任务的提交.执行,线程重用和线程数维护等方面做下分析. 0.    ThreadPoolExecutor类的声明属性变量分析 1 public class ThreadPoolExecutor extends AbstractExecutorService 从这个类声明中我们可以看到java.u

基于同步对象的等待.唤醒机制: 一个线程可以等待一个对象或多个对象而进入等待状态(也叫睡眠状态),另一个线程可以触发那个等待对象,唤醒在那个对象上等待的所有线程. 一个线程可以等待一个对象或多个对象,而一个对象也可以同时被N个线程等待.这样,线程与等待对象之间是多对多的关系.他们之间的等待关系由一个队列和一个'等待块'来控制,等待块就是线程与等待目标对象之间的纽带. WaitForSingleObject可以等待那些"可等待对象",哪些对象是'可等待'的呢?进程.线程.作业.文件对象.

示例代码: public class CPULockTest { private static Object lock1 = new Object(); private static Object lock2 = new Object(); public static void main(String[] args) { new Thread(()->{ synchronized (lock1){ try { System.out.println(Thread.currentThread().g

带着几个问题进入源码分析: 1. 线程池是什么时候创建线程的? 2. 任务runnable task是先放到core到maxThread之间的线程,还是先放到队列? 3. 队列中的任务是什么时候取出来的? 4. 什么时候会触发reject策略? 5. core到maxThread之间的线程什么时候会die? 6. task抛出异常,线程池中这个work thread还能运行其他任务吗? 先写一段基础代码,进入分析 public static void main(String[] args) {

1. 问题 最近有同事问了我一个问题,在Java编程中,当有一条线程要获取ReentrantReadWriteLock的读锁,此时已经有其他线程获得了读锁,AQS队列里也有线程在等待写锁.由于读锁是共享锁,当前线程是马上获得读锁,还是排队?如果是马上获得读锁,那岂不是阻塞的等待写锁的线程有可能一直(或长时间)拿不到写锁(写锁饥饿)? 带着这个问题,我打开读写锁的源码,来看一下JDK是怎么实现的.(注:读写锁指ReentrantReadWriteLock, 以下说到的读锁和写锁,都是指属于同一个读