java8 去除 永久代, metaspace (元空间) 在过去 (当自定义类加载器使用不普遍的时候) ,类几乎是"静态的"并且很少被卸载和回收, 因此类也可以被看成"永久的"。另外由于类作为JVM实现的一部分,它们不由程序来创建,因为它们也被认为是"非堆"的内存。 在JDK8之前的 HotSpot虚拟机中,类的这些"永久的"数据存放在一个叫做永久代的区域。永久代一段连续的内存空间,我们在JVM启动之前可以通过设置-XX:MaxPermSize 的值来控制永久代的大小, 32位机器默认的永久代的大小为64M, 64位的机器则为85M。永久代的垃圾回收和老年代的垃圾回收是绑定的,一旦其中一个区域被占满, 这两个区都要进行垃圾回收。但是有一个明显的问题, 由于我们可以通过‑XX:MaxPermSize 设置永久代的大小,一旦类的元数据超过了设定的大小, 程序就会耗尽内存,并出现内存溢出错误(OOM)。 备注: 在JDK7之前的 HotSpot虚拟机中, 纳入字符串常量池的字符串被存储在永久代中, 因此导致了一系列的性能问题和内存溢出错误。 http://www.cnblogs.com/moonandstar08/p/5001914.html 这项改动是很有必要的, 因为对永久代进行调优是很困难的。 永久代中的元数据可能会随着每一次 Full GC发生而进行移动。并且为永久代设置空间大小也是很难确定的, 因为这其中有很多影响因素,比如类的总数,常量池的大小和方法数量等。 同时,HotSpot 虚拟机的每种类型的垃圾回收器都需要特殊处理永久代中的元数据。将元数据从永久代剥离出来, 不仅实现了对元空间的无缝管理, 还可以简化Full GC以及对以后的并发隔离类元数据等方面进行优化。 新增加的 metaspace (元空间) 持久代的空间被彻底地删除了, 它被一个叫元空间的区域所替代了。 持久代删除了之后,很明显, JVM会忽略 PermSize 和 MaxPermSize 这两个参数,还有就是你再也看不到 java.lang.OutOfMemoryError: PermGen error 的异常了。 JDK 8 的 HotSpot JVM 现在使用的是本地内存来表示类的元数据,这个区域就叫做元空间。 元空间存储类的元信息，静态变量和常量池等并入堆中。相当于永久代的数据被分到了堆和元空间中。 元空间的特点: 充分利用了Java语言规范中的好处: 类及相关的元数据的生命周期与类加载器的一致。 每个加载器有专门的存储空间 只进行线性分配 不会单独回收某个类 省掉了GC扫描及压缩的时间 元空间里的对象的位置是固定的 如果GC发现某个类加载器不再存活了,会把相关的空间整个回收掉 元空间的内存分配模型 绝大多数的类元数据的空间都从本地(native)内存中分配 用来描述类元数据的类也被删除了 分元数据分配了多个虚拟内存空间 给每个类加载器分配一个内存块的列表。块的大小取决于类加载器的类型; sun/反射/代理对应的类加载器的块会小一些 归还内存块,释放内存块列表 一旦元空间的数据被清空了,虚拟内存的空间会被回收掉 减少碎片的策略 ...

/dev/shm http://dbua.iteye.com/blog/1271574 1.linux下的/dev/shm是什么？ /dev/shm/是linux下一个目录,/dev/shm目录不在磁盘上,而是在内存里,因此使用linux /dev/shm/的效率非常高,直接写进内存。 我们可以通过以下两个脚本来验证linux /dev/shm的性能: [root@db1 oracle]# ls -l linux_11gR2_grid.zip -rw-r-r- 1 oracle dba 980831749 Jul 11 20:18 linux_11gR2_grid.zip [root@db1 oracle]# cat mycp.sh !/bin/sh echo date cp linux_11gR2_grid.zip .. echo date [root@db1 oracle]# ./mycp.sh Fri Jul 15 18:44:17 CST 2011 Fri Jul 15 18:44:29 CST 2011 [root@db1 shm]# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/rootvg-lv01 97G 9.2G 83G 10% / /dev/sda1 99M 15M 80M 16% /boot ...

sar command sar -n DEV 1 sar -n TCP,ETCP 1 Cannot open /var/log/sa/sa22: No such file or directory 22 是指当天的日期 这个是由于没有创建那sa22这个文件,这可以通过参数-o让其生成 sar -o 2 3 在对应的/var/log/sa/目录下就有对应的日志文件了 在运行就不会报错了 还有另外一种情况,因为刚刚装上sar所以还没有数据在/var/log/sa/sa22下,因为sar -n DEV 默认是是过去十分钟的系统活动报告。 pacman -S sysstat sar 找出系统瓶颈的利器 sar是System Activity Reporter (系统活动情况报告) 的缩写。sar工具将对系统当前的状态进行取样,然后通过计算数据和比例来表达系统的当前运行状态。它的特点是可以连续对系统取样,获得大量的取样数据；取样数据和分析的结果都可以存入文件,所需的负载很小。sar是目前Linux上最为全面的系统性能分析工具之一,可以从14个大方面对系统的活动进行报告,包括文件的读写情况、系统调用的使用情况、串口、CPU效率、内存使用状况、进程活动及IPC有关的活动等,使用也是较为复杂。 sar是查看操作系统报告指标的各种工具中,最为普遍和方便的；它有两种用法； 追溯过去的统计数据 (默认) 周期性的查看当前数据 12.1. 追溯过去的统计数据 默认情况下,sar从最近的0点0分开始显示数据；如果想继续查看一天前的报告；可以查看保存在/var/log/sysstat/下的sa日志； 使用sar工具查看: $sar -f /var/log/sysstat/sa28 | head sar -r -f /var/log/sysstat/sa28 ../_images/sar1.png 12.2. 查看CPU使用率 sar -u : 默认情况下显示的cpu使用率等信息就是sar -u； ../_images/sar2.png 可以看到这台机器使用了虚拟化技术,有相应的时间消耗； 各列的指标分别是: %user 用户模式下消耗的CPU时间的比例； %nice 通过nice改变了进程调度优先级的进程,在用户模式下消耗的CPU时间的比例 %system 系统模式下消耗的CPU时间的比例； ...

busybox BusyBox 是一个提供了很多简化版的Unix 工具的一个可执行文件, busybox能在很多POSIX环境运行,比如Linux,Android,FreeBSD. BusyBox最初是由布鲁斯·斐伦斯在1996年为Debian GNU/Linux安装光盘而编写 Busybox只提供每个工具程序的简化版 (例如: ls指令不提供排序功能) 。 BusyBox 是一个集成了一百多个最常用linux命令和工具的软件,他甚至还集成了一个http服务器和一个telnet服务器,而所有这一切功能却只有区区1M左右的大小。BusyBox 包含了一些简单的工具,比如: 我们平时用的那些linux命令就好比是分立式的电子元件,而busybox就好比是一个集成电路,把常用的工具和命令集成压缩在一个可执行文件里,功能基本不变,而大小却小很多倍,例如ls、 cat 和 echo等等,还包含了一些更大、更复杂的工具,例如 grep、find、mount 以及telnet。简单的说BusyBox就好像是个大工具箱,它集成压缩了 Linux 的许多工具和命令,也包含了 Android 系统自带的shell。BusyBox 将许多具有共性的小版本的UNIX工具结合到一个单一的可执行文件。这样的集合可以替代大部分常用工具比如: GNU 等工具,BusyBox提供了一个比较完善的环境,可以适用于任何小的或嵌入式系统。在嵌入式linux应用中,busybox有非常广的应用,另外,大多数linux发行版的安装程序中都有busybox的身影,安装linux的时候案ctrl+alt+F2可以切换物理终端,而这个物理终端中的所有命令都是指向busybox的链接.Busybox虽小,但作用确是惊人的,这样就可以基于Busybox制作一张软盘linux。 http://jilili.blog.51cto.com/6617089/1170368 https://busybox.net/ https://en.wikipedia.org/wiki/BusyBox

java 监视器 http://ifeve.com/monitors-java-synchronization-mechanism/ 监视器–JAVA同步基本概念 大学有一门课程叫操作系统,学习过的同学应该都记得,监视器是操作系统实现同步的重要基础概念,同样它也用在JAVA的线程同步中,这篇文章用一种类推的思想解释监视器"monitor"。 1.什么是监视器 监视器可以看做是经过特殊布置的建筑,这个建筑有一个特殊的房间,该房间通常包含一些数据和代码,但是一次只能一个消费者(thread)使用此房间, Java-Monitor 当一个消费者(线程)使用了这个房间,首先他必须到一个大厅(Entry Set)等待,调度程序将基于某些标准(e.g. FIFO)将从大厅中选择一个消费者(线程),进入特殊房间,如果这个线程因为某些原因被"挂起",它将被调度程序安排到"等待房间",并且一段时间之后会被重新分配到特殊房间,按照上面的线路,这个建筑物包含三个房间,分别是"特殊房间"、“大厅"以及"等待房间”。 java-monitor-associate-with-object 简单来说,监视器用来监视线程进入这个特别房间,他确保同一时间只能有一个线程可以访问特殊房间中的数据和代码。 2.JAVA中监视器的实现 在JAVA虚拟机中,每个对象(Object和class)通过某种逻辑关联监视器,为了实现监视器的互斥功能,每个对象(Object和class)都关联着一个锁(有时也叫"互斥量"),这个锁在操作系统书籍中称为"信号量",互斥(“mutex “)是一个二进制的信号量。 如果一个线程拥有了某些数据的锁,其他的线程则无法获得锁,直到这个线程释放了这个锁。在多线程中,如果任何时候都是我们自己来写这个信号量,显然不是很方便,幸运的是,JVM为我们自动实现了这些。 为了使数据不被多个线程访问,java 提供了同步块 以及 同步方法两种实现,一旦一段代码被嵌入到一个synchronized关键字中,意味着放入了监视区域,JVM在后台会自动为这段代码实现锁的功能。 3.JAVA的同步代码中,哪一部分是监视器？ 我们知道JAVA每个对象(Object/class) 都关联一个监视器,更好的说法应该是每个对象(Object/class)都有一个监视器,对象可以有它自己的临界区,并且能够监视线程序列为了使线程协作,JAVA为提供了wait()和notifyAll以及notify()实现挂起线程,并且唤醒另外一个等待的线程,此外这些方法有三种不同版本: wait(long timeout, int nanos) wait(long timeout) notified by other threads or notified by timeout. notify(all) 这些方法只能在一个同步块或同步方法中被调用,原因是,如果一个方法不需要相互排斥,不需要监测或线程之间协作,每一个线程可以自由访问此方法,那就不需要协作。

hbase BufferedMutator org.apache.hadoop.hbase.client.BufferedMutator主要用来对HBase的单个表进行操作。它和Put类的作用差不多,但是主要用来实现批量的异步写操作。 BufferedMutator替换了HTable的setAutoFlush(false)的作用。 可以从Connection的实例中获取BufferedMutator的实例。在使用完成后需要调用close()方法关闭连接。对BufferedMutator进行配置需要通过BufferedMutatorParams完成。 MapReduce Job的是BufferedMutator使用的典型场景。MapReduce作业需要批量写入,但是无法找到恰当的点执行flush。BufferedMutator接收MapReduce作业发送来的Put数据后,会根据某些因素 (比如接收的Put数据的总量) 启发式地执行Batch Put操作,且会异步的提交Batch Put请求,这样MapReduce作业的执行也不会被打断。 BufferedMutator也可以用在一些特殊的情况上。MapReduce作业的每个线程将会拥有一个独立的BufferedMutator对象。一个独立的BufferedMutator也可以用在大容量的在线系统上来执行批量Put操作,但是这时需要注意一些极端情况比如JVM异常或机器故障,此时有可能造成数据丢失。

堆内内存, 堆外内存 一、什么是堆外内存 堆内内存 (on-heap memory) 回顾 堆外内存和堆内内存是相对的二个概念,其中堆内内存是我们平常工作中接触比较多的,我们在jvm参数中只要使用-Xms,-Xmx等参数就可以设置堆的大小和最大值,理解jvm的堆还需要知道下面这个公式: 堆内内存 = 新生代+老年代+持久代 如下面的图所示: Paste_Image.png 在使用堆内内存 (on-heap memory) 的时候,完全遵守JVM虚拟机的内存管理机制,采用垃圾回收器 (GC) 统一进行内存管理,GC会在某些特定的时间点进行一次彻底回收,也就是Full GC,GC会对所有分配的堆内内存进行扫描,在这个过程中会对JAVA应用程序的性能造成一定影响,还可能会产生Stop The World。 常见的垃圾回收算法主要有: 引用计数器法 (Reference Counting) 标记清除法 (Mark-Sweep) 复制算法 (Coping) 标记压缩法 (Mark-Compact) 分代算法 (Generational Collecting) 分区算法 (Region) 注: 在这里我们不对各个算法进行深入介绍,感兴趣的同学可以关注我的下一篇关于垃圾回收算法的介绍分享。 堆外内存 (off-heap memory) 介绍 和堆内内存相对应,堆外内存就是把内存对象分配在Java虚拟机的堆以外的内存,这些内存直接受操作系统管理 (而不是虚拟机) ,这样做的结果就是能够在一定程度上减少垃圾回收对应用程序造成的影响。 作为JAVA开发者我们经常用java.nio.DirectByteBuffer对象进行堆外内存的管理和使用,它会在对象创建的时候就分配堆外内存。 DirectByteBuffer类是在Java Heap外分配内存,对堆外内存的申请主要是通过成员变量unsafe来操作,下面介绍构造方法 DirectByteBuffer(int cap) { super(-1, 0, cap, cap); //内存是否按页分配对齐 boolean pa = VM.isDirectMemoryPageAligned(); //获取每页内存大小 int ps = Bits.pageSize(); //分配内存的大小,如果是按页对齐方式,需要再加一页内存的容量 long size = Math.max(1L, (long)cap + (pa ? ps : 0)); //用Bits类保存总分配内存(按页分配)的大小和实际内存的大小 Bits.reserveMemory(size, cap); long base = 0; try { //在堆外内存的基地址,指定内存大小 base = unsafe.allocateMemory(size); } catch (OutOfMemoryError x) { Bits.unreserveMemory(size, cap); throw x; } unsafe.setMemory(base, size, (byte) 0); //计算堆外内存的基地址 if (pa && (base % ps != 0)) { // Round up to page boundary address = base + ps - (base & (ps - 1)); } else { address = base; } cleaner = Cleaner.create(this, new Deallocator(base, size, cap)); att = null; } 注: 在Cleaner 内部中通过一个列表,维护了一个针对每一个 directBuffer 的一个回收堆外内存的 线程对象(Runnable),回收操作是发生在 Cleaner 的 clean() 方法中。 ...

CLH队列,CLH锁 CLH的发明人是: Craig,Landin and Hagersten。 CLH锁即 Craig, Landin, and Hagersten (CLH) locks CLH锁是一个自旋锁,能确保无饥饿性,提供先来先服务的公平性。 CLH锁是一种基于链表的可扩展、高性能、公平的自旋锁,申请线程只在本地变量上自旋,它不断轮询前驱的状态,如果发现前驱释放了锁就结束自旋。 CLH算法实现 CLH队列锁表示为QNode对象的链表,QNode中含有一个locked字段,该字段若为true表示该线程需要获取锁,且不释放锁,为false表示线程释放了锁。结点之间是通过隐形的链表相连,之所以叫隐形的链表是因为这些结点之间没有明显的next指针,每个线程通过一个线程局部变量pred指向其前驱,线程通过检测前驱结点的locked域来判断是否轮到自己。如果该域为true,则前驱线程要么已经获得锁要么正在等待锁；如果该域为false,则前驱进程已释放锁,轮到自己了。正常情况下,队列链中只有一个结点的locked域为false。CLHLock上还有一个尾指针,始终指向队列的最后一个结点。 当一个线程调用lock()方法想获得锁时,将自己的locked域置为true,表示该线程不准备释放锁,然后并将自己的结点加入到队列链尾部。最后就是在前驱的locked域上旋转,等待前驱释放锁。当这个线程调用unlock()方法要释放锁时,线程要将自己的locked域置为false,表示已经释放锁,然后将前驱结点作为自己的新结点以便日后访问。 //clh 1 class ClhSpinLock { private final ThreadLocal<Node> prev; private final ThreadLocal<Node> node; private final AtomicReference<Node> tail = new AtomicReference<Node>(new Node()); public ClhSpinLock() { this.node = new ThreadLocal<Node>() { protected Node initialValue() { return new Node(); } }; this.prev = new ThreadLocal<Node>() { protected Node initialValue() { return null; } }; } public void lock() { final Node node = this.node.get(); node.locked = true; // 一个CAS操作即可将当前线程对应的节点加入到队列中, // 并且同时获得了前继节点的引用,然后就是等待前继释放锁 Node pred = this.tail.getAndSet(node); this.prev.set(pred); while (pred.locked) {// 进入自旋 } } public void unlock() { final Node node = this.node.get(); node.locked = false;// 改变状态,让后续线程结束自旋 this.node.set(this.prev.get()); } private static class Node { private volatile boolean locked; } } //clh 2 import java.util.concurrent.atomic.AtomicReferenceFieldUpdater; public class CLHLock { public static class CLHNode { private volatile boolean isLocked = true; // 默认是在等待锁 } @SuppressWarnings("unused" ) private volatile CLHNode tail ; private static final AtomicReferenceFieldUpdater<CLHLock, CLHNode> UPDATER = AtomicReferenceFieldUpdater .newUpdater(CLHLock.class, CLHNode .class , "tail" ); public void lock(CLHNode currentThread) { CLHNode preNode = UPDATER.getAndSet( this, currentThread); if(preNode != null) {//已有线程占用了锁,进入自旋 while(preNode.isLocked ) { } } } public void unlock(CLHNode currentThread) { // 如果队列里只有当前线程,则释放对当前线程的引用 (for GC) 。 if (!UPDATER.compareAndSet(this, currentThread, null)) { // 还有后续线程 currentThread.isLocked = false ;// 改变状态,让后续线程结束自旋 } } } NUMA与SMP SMP ( Symmetric Multi-Processor ) , 对称多处理器结构 对称多处理器结构,指服务器中多个CPU对称工作,每个CPU访问内存地址所需时间相同。其主要特征是共享,包含对CPU,内存,I/O等进行共享。SMP的优点是能够保证内存一致性,缺点是这些共享的资源很可能成为性能瓶颈,随着CPU数量的增加,每个CPU都要访问相同的内存资源,可能导致内存访问冲突,可能会导致CPU资源的浪费。常用的PC机就属于这种。 ...

Java8 jdeps http://blog.csdn.net/u013803262/article/details/70570161 Java8中带了一个新的类依赖分析器。 我们可以在Java的安装目录的bin目录下看到jdeps.exe这个文件。 这个工具是用于分析类的依赖关系的。 具体怎么用 可以这样。 找一个目录,下面全是jar文件。那么这样的目录很明显WEB-INF下的lib目录就非常合适。 假设我们有一个web项目,tomcat下的lib有 commons-pool2-2.0.jar jedis-2.5.1.jar 为了使得结构简单点。我们只加入了两个jar包并且jedis包依赖于commons-pool这个包。 我们进入lib目录下运行命令 jdeps *.jar 结果得到 E:\git_tmp\distributedSession\target\distributedSession\WEB-INF\lib>jdeps *.jar commons-pool2-2.0.jar -> F:\Program Files\Java\jdk1.8.0_121\jre\lib\rt.jar commons-pool2-2.0.jar -> 找不到 org.apache.commons.pool2 (commons-pool2-2.0.jar) -> java.io -> java.lang -> java.util -> java.util.concurrent.locks org.apache.commons.pool2.impl (commons-pool2-2.0.jar) -> java.io -> java.lang -> java.lang.management -> java.lang.ref -> java.lang.reflect -> java.security -> java.text -> java.util -> java.util.concurrent -> java.util.concurrent.atomic -> java.util.concurrent.locks -> javax.management -> org.apache.commons.pool2 commons-pool2-2.0.jar org.apache.commons.pool2.proxy (commons-pool2-2.0.jar) -> java.lang -> java.lang.reflect ...

Deprecate HTablePool https://issues.apache.org/jira/browse/HBASE-6580 http://blog.csdn.net/jiyiqinlovexx/article/details/36526433 http://blog.csdn.net/u010967382/article/details/38046821

HBase的WAL机制 WAL (Write-Ahead-Log) WAL机制解析 WAL(Write-Ahead Logging)是一种高效的日志算法,几乎是所有非内存数据库提升写性能的不二法门,基本原理是在数据写入之前首先顺序写入日志,然后再写入缓存,等到缓存写满之后统一落盘。之所以能够提升写性能,是因为WAL将一次随机写转化为了一次顺序写加一次内存写。提升写性能的同时,WAL可以保证数据的可靠性,即在任何情况下数据不丢失。假如一次写入完成之后发生了宕机,即使所有缓存中的数据丢失,也可以通过恢复日志还原出丢失的数据。 WAL持久化等级 HBase中可以通过设置WAL的持久化等级决定是否开启WAL机制、以及HLog的落盘方式。WAL的持久化等级分为如下四个等级: SKIP_WAL: 只写缓存,不写HLog日志。这种方式因为只写内存,因此可以极大的提升写入性能,但是数据有丢失的风险。在实际应用过程中并不建议设置此等级,除非确认不要求数据的可靠性。 ASYNC_WAL: 异步将数据写入HLog日志中。 SYNC_WAL: 同步将数据写入日志文件中,需要注意的是数据只是被写入文件系统中,并没有真正落盘。 FSYNC_WAL: 同步将数据写入日志文件并强制落盘。最严格的日志写入等级,可以保证数据不会丢失,但是性能相对比较差。 USER_DEFAULT: 默认如果用户没有指定持久化等级,HBase使用SYNC_WAL等级持久化数据。 用户可以通过客户端设置WAL持久化等级,代码: put.setDurability(Durability. SYNC_WAL ); HLog数据结构 HBase中,WAL的实现类为HLog,每个Region Server拥有一个HLog日志,所有region的写入都是写到同一个HLog。下图表示同一个Region Server中的3个 region 共享一个HLog。当数据写入时,是将数据对<HLogKey,WALEdit>按照顺序追加到HLog中,以获取最好的写入性能。 WAL(Write-Ahead-Log)预写日志是HBase的RegionServer在处理数据插入和删除的过程中用来记录操作内容的一种日志。在每次Put、Delete等一条记录时,首先将其数据写入到RegionServer对应的HLog文件的过程。 客户端往RegionServer端提交数据的时候,会先写WAL日志,只有当WAL日志写成功以后,客户端才会被告诉提交数据成功,如果写WAL失败会告知客户端提交失败,换句话说这其实是一个数据落地的过程。 在一个RegionServer上的所有的Region都共享一个HLog,一次数据的提交是先写WAL,写入成功后,再写memstore。当memstore值到达一定是,就会形成一个个StoreFile (理解为HFile格式的封装,本质上还是以HFile的形式存储的) 。 HLog类 RegionServer内WAL文件与Region的关系图 WAL的实现类是HLog,当一个Region被初始化的时候,一个HLog的实例会作为构造函数的参数传进去。 当Region在处理Put、Delete等更新操作时,可以直接使用该共享的HLog的append方法来落地数据。 Put、Delete在客户端上可以通过setWriteToWAL(false)方法来关闭该操作的日志,这么做虽然可以提升入库速度,但最好别这么做,因为有数据丢失的风险存在。 http://www.zkread.com/article/69288.html http://hbasefly.com/2016/03/23/hbase_writer/

锁定读, 一致性非锁定读 http://ju.outofmemory.cn/entry/275548 锁定读 (Locking Reads) 在一个事务中查询数据时,普通的SELECT语句不会对查询的数据进行加锁,其他事务仍可以对查询的数据执行更新和删除操作。因此,InnoDB提供了两种类型的锁定读来保证额外的安全性: - SELECT … LOCK IN SHARE MODE - SELECT … FOR UPDATE SELECT … LOCK IN SHARE MODE: 对读取的行添加S锁,其他事物可以对这些行添加S锁,若添加X锁,则会被阻塞。 SELECT … FOR UPDATE: 会对查询的行及相关联的索引记录加X锁,其他事务请求的S锁或X锁都会被阻塞。 当事务提交或回滚后,通过这两个语句添加的锁都会被释放。 注意: 只有在自动提交被禁用时, SELECT FOR UPDATE 才可以锁定行, 若开启自动提交, 则匹配的行不会被锁定。 一致性非锁定读 (Consistent Nonlocking Reads) MySQL官方文档对弈一致性读的定义: > A consistent read means that InnoDB uses multi-versioning to present to a query a snapshot of the database at a point in time. 就是说: 一致性读意味着InnoDB使用多版本控制来实现一个查询,这个查询所依赖的数据是基于某个时间点的数据库快照。 注意: 是数据库的快照,而不是要查询的那个表的快照。 在事务隔离级别设置为READ COMMITTED和REPEATABLE READ时,默认情况下InnoDB是通过一致性读来处理SELECT语句的。一致性读不会对它访问的表设置任何锁,因此,在一个表上进行一致性读的同时,其他session可以随意修改这些表。 一致性读是使用基于时间点的快照信息来呈现查询结果的读取操作,而不管其他事务在同一时间产生的变更。如果查询的数据已被其他事务改变,InnoDB会基于undo log的内容来重建最初的数据。 两种事务隔离级别下,读取的快照数据的区别: - 在REPEATABLE READ事务隔离级别下,同一事务内的所有一致性读都会读取到该事务中第一个一致性读建立的快照。通过提交当前事务并发起一个新的查询,可以看得到新的快照。 - 在READ COMMITTED事务隔离级别下,同一事务内的每个一致性读总是读取本次一致性读建立的快照。(即,快照的时间点是基于本次一致性读的时间点,也就是最新的数据) 假设当前事务隔离级别为REPEATABLE READ,当发出一个一致性读(也就是一个普通的SELECT语句)时,InnoDB会根据这个查询给此事务分配一个时间点。若其他事务在此时间点之后删除了一行并提交,那么此事务不会看到其他事务产生的影响(即,还是会看到被删除的行)。插入和更新操作也一样。

MVCC, Multiversion Concurrency Control, 多版本并发控制 http://donghui.blog.51cto.com/2709336/692586 多版本并发控制技术已经被广泛运用于各大数据库系统中,如 Oracle, MS SQL Server 2005+, Postgresql, Firebird, Maria 等等, 开源数据库 MySQL 中流行的 INNODB 引擎也采用了类似的并发控制技术.本文就将结合实例来解析不同事务隔离等级下 INNODB 的 MVCC 实现原理. 1.1 MVCC 简介 MVCC (Multiversion Concurrency Control), 即多版本并发控制技术, 它使得大部分支持行锁的事务引擎, 不再单纯的使用行锁来进行数据库的并发控制, 取而代之的是, 把数据库的行锁与行的多个版本结合起来, 只需要很小的开销, 就可以实现非锁定读, 从而大大提高数据库系统的并发性能. 1.2 实现原理 MVCC 可以提供基于某个时间点的快照, 使得对于事务看来, 总是可以提供与事务开始时刻相一致的数据, 而不管这个事务执行的时间有多长. 所以在不同的事务看来, 同一时刻看到的相同行的数据可能是不一样的, 即一个行可能有多个版本. 是否听起来不可思议呢? 原来, 为了实现 mvcc, innodb 对每一行都加上了两个隐含的列, 其中一列存储行被更新的"时间", 另外一列存储行被删除的"时间". 但是 innodb 存储的并不是绝对的时间, 而是与时间对应的数据库系统的版本号, 每当一个事务开始的时候, innodb 都会给这个事务分配一个递增的版本号, 所以版本号也可以被认为是事务号. 对于每一个"查询"语句, innodb 都会把这个查询语句的版本号同这个查询语句遇到的行的版本号进行对比, 然后结合不同的事务隔离等级, 来决定是否返回该行. ...

Locked ownable synchronizers An ownable synchronizer is a synchronizer that may be exclusively owned by a thread and uses AbstractOwnableSynchronizer (or its subclass) to implement its synchronization property. ReentrantLock and ReentrantReadWriteLock are two examples of ownable synchronizers provided by the platform. http://stackoverflow.com/questions/41300520/what-is-locked-ownable-synchronizers-in-thread-dump

java jps jps位于jdk的bin目录下,其作用是显示当前系统的java进程情况,及其id号。 jps相当于Solaris进程工具ps。不象"pgrep java"或"ps -ef grep java",jps并不使用应用程序名来查找JVM实例。因此,它查找所有的Java应用程序,包括即使没有使用java执行体的那种 (例如,定制的启动 器) 。另外,jps仅查找当前用户的Java进程,而不是当前系统中的所有进程。 -h: help -l: 输出应用程序main class的完整package名 或者 应用程序的jar文件完整路径名 -m: 输出传递给main 方法的参数,在嵌入式jvm上可能是null, 在这里,在启动main方法的时候,我给String[] args传递两个参数。hollis,chuang,执行jsp -m: -v: 输出传递给JVM的参数 在这里,在启动main方法的时候,我给jvm传递一个参数: -Dfile.encoding=UTF-8,执行jps -v: 位置 我们知道,很多Java命令都在jdk的JAVA_HOME/bin/目录下面,jps也不例外,他就在bin目录下,所以,他是java自带的一个命令。 功能 jps(Java Virtual Machine Process Status Tool)是JDK 1.5提供的一个显示当前所有java进程pid的命令,简单实用,非常适合在linux/unix平台上简单察看当前java进程的一些简单情况。 原理 jdk中的jps命令可以显示当前运行的java进程以及相关参数,它的实现机制如下: java程序在启动以后,会在java.io.tmpdir指定的目录下,就是临时文件夹里,生成一个类似于hsperfdata_User的文件夹,这个文件夹里 (在Linux中为/tmp/hsperfdata_{userName}/) ,有几个文件,名字就是java进程的pid,因此列出当前运行的java进程,只是把这个目录里的文件名列一下而已。 至于系统的参数什么,就可以解析这几个文件获得。 hollis@hos:/tmp/hsperfdata_hollis$ pwd /tmp/hsperfdata_hollis hollis@hos:/tmp/hsperfdata_hollis$ ll total 48 drwxr-xr-x 2 hollis hollis 4096 4月 16 10:54 ./ drwxrwxrwt 7 root root 12288 4月 16 10:56 ../ ...

自旋锁/Spin lock public class SpinLock { private AtomicReference<Thread> sign =new AtomicReference<>(); public void lock(){ Thread current = Thread.currentThread(); while(!sign.compareAndSet(null, current)){ } } public void unlock (){ Thread current = Thread.currentThread(); sign.compareAndSet(current, null); } } // another spin lock for (;;) { if (condition == true) break; } 自旋锁是为实现保护共享资源而提出一种锁机制。其实,自旋锁与互斥锁比较类似,它们都是为了解决对某项资源的互斥使用。无论是互斥锁,还是自旋锁,在任何时刻,最多只能有一个保持者,也就说,在任何时刻最多只能有一个执行单元获得锁。但是两者在调度机制上略有不同。对于互斥锁,如果资源已经被占用,资源申请者只能进入睡眠状态。但是自旋锁不会引起调用者睡眠,如果自旋锁已经被别的执行单元保持,调用者就一直循环在那里看是否该自旋锁的保持者已经释放了锁,“自旋"一词就是因此而得名。 自旋锁适用于锁保护的临界区很小的情况,临界区很小的话,锁占用的时间就很短。 自旋锁一般原理 跟互斥锁一样,一个执行单元要想访问被自旋锁保护的共享资源,必须先得到锁,在访问完共享资源后,必须释放锁。如果在获取自旋锁时,没有任何执行单元保持该锁,那么将立即得到锁；如果在获取自旋锁时锁已经有保持者,那么获取锁操作将自旋在那里,直到该自旋锁的保持者释放了锁。由此我们可以看出,自旋锁是一种比较低级的保护数据结构或代码片段的原始方式,这种锁可能存在两个问题: 死锁和过多占用cpu资源。 自旋锁适用情况 ...

kafka config, server, producer 大体上来说,用户首先构建待发送的消息对象ProducerRecord,然后调用KafkaProducer#send方法进行发送。KafkaProducer接收到消息后首先对其进行序列化,然后结合本地缓存的元数据信息一起发送给partitioner去确定目标分区,最后追加写入到内存中的消息缓冲池(accumulator)。此时KafkaProducer#send方法成功返回。 KafkaProducer中还有一个专门的Sender IO线程负责将缓冲池中的消息分批次发送给对应的broker,完成真正的消息发送逻辑。 基本设计特点 结合源代码,笔者认为新版本的producer从设计上来说具有以下几个特点(或者说是优势): 总共创建两个线程: 执行KafkaPrducer#send逻辑的线程——我们称之为"用户主线程"；执行发送逻辑的IO线程——我们称之为"Sender线程" 不同于Scala老版本的producer,新版本producer完全异步发送消息,并提供了回调机制(callback)供用户判断消息是否成功发送 batching机制——“分批发送"机制。每个批次(batch)中包含了若干个PRODUCE请求,因此具有更高的吞吐量 更加合理的默认分区策略: 对于无key消息而言,Scala版本分区策略是一段时间内(默认是10分钟)将消息发往固定的目标分区,这容易造成消息分布的不均匀,而新版本的producer采用轮询的方式均匀地将消息分发到不同的分区 底层统一使用基于 Selector 的网络客户端实现, 结合 Java 提供的 Future 实现完整地提供了更加健壮和优雅的生命周期管理。 其实,新版本 producer 的设计优势还有很多, 诸如监控指标更加完善等这样的就不一一细说了。总之, 新版本producer更加地健壮,性能更好~ Kafka新版本clients在设计底层网络库时采用了Java的Selector机制，而后者在 Linux上的实现机制就是 epoll；但是在 Windows平台上，Java NIO的 Selector 底层是使用 select模型而非IOCP 实现的，只有 Java NIO2才是使用 IOCP 实现的。因此在这一点上，在 Linux 上部署Kafka要比在Windows上部署能够得到更高效的I/O处理性能。 properties props = new Properties(); props.put("bootstrap.servers", "localhost:9092"); props.put("acks", "all"); props.put("retries", 0); props.put("batch.size", 16384); props.put("linger.ms", 1); props.put("buffer.memory", 33554432); props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer"); props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer"); Producer<String, String> producer = new KafkaProducer<>(props); for(int i = 0; i < 100; i++) producer.send(new ProducerRecord<String, String>("my-topic", Integer.toString(i), Integer.toString(i))); producer.close(); bootstrap.servers 配置kafka 查询集群 metadata 服务的地址, 建立连接时,kafa producer向 bootstrap.servers 发 metadata 请求, 从 返回 的metadata response里得到kafka 集群的地址,再建立连接 ...

systemtap http://www.cnblogs.com/hazir/p/systemtap_introduction.html 内核探测工具systemtap简介 systemtap是内核开发者必须要掌握的一个工具,本文我将简单介绍一下此工具,后续将会有系列文章介绍systemtap的用法。 什么是systemtap 假如现在有这么一个需求: 需要获取正在运行的 Linux 系统的信息,如我想知道系统什么时候发生系统调用,发生的是什么系统调用等这些信息,有什么解决方案呢？ 最原始的方法是,找到内核系统调用的代码,加上我们需要获得信息的代码、重新编译内核、安装、选择我们新编译的内核重启。这种做法对于内核开发人员简直是梦魇,因为一遍做下来至少得需要1个多小时,不仅破坏了原有内核代码,而且如果换了一个需求又得重新做一遍上面的工作。所以,这种调试内核的方法效率是极其底下的。 之后内核引入了一种Kprobe机制,可以用来动态地收集调试和性能信息的工具,是一种非破坏性的工具,用户可以用它跟踪运行中内核任何函数或执行的指令等。相比之前的做法已经有了质的提高了,但Kprobe并没有提供一种易用的框架,用户需要自己去写模块,然后安装,对用户的要求还是蛮高的。 systemtap 是利用Kprobe 提供的API来实现动态地监控和跟踪运行中的Linux内核的工具,相比Kprobe,systemtap更加简单,提供给用户简单的命令行接口,以及编写内核指令的脚本语言。对于开发人员,systemtap是一款难得的工具。 下面将会介绍systemtap的安装、systemtap的工作原理以及几个简单的示例。 systemtap 的安装 我的主机 Linux 发行版是32位 Ubuntu13.04,内核版本 3.8.0-30。由于 systemtap 运行需要内核的调试信息支撑,默认发行版的内核在配置时这些调试开关没有打开,所以安装完systemtap也是无法去探测内核信息的。 下面我以两种方式安装并运行 systemtap: 方法一 编译内核以支持systemtap 我们重新编译内核让其支持systemtap,首先你想让内核中有调试信息,编译内核时需要加上 -g 标志；其次,你还需要在配置内核时将 Kprobe 和 debugfs 开关打开。最终效果是,你能在内核 .config 文件中看到下面四个选项是设置的: CONFIG_DEBUG_INFO CONFIG_KPROBES CONFIG_DEBUG_FS CONFIG_RELAY 配置完之后,按照之前你编译内核的步骤编译即可。 获取systemtap源码 从此地址 https://sourceware.org/systemtap/ftp/releases下载已经发布的systemtap的源代码,截至目前 (2013.9.17) 最新版本为systemtap-2.3。下载完之后解压。 当然你还可以使用 git 去克隆最新的版本 (2.4) ,命令如下: git clone git://sources.redhat.com/git/systemtap.git 编译安装systemtap 如果你下载的是最新版本的systemtap,那么你需要新版的 elfutils,可以从https://fedorahosted.org/releases/e/l/elfutils/ 下载elfutils-0.156 版本。下载之后解压缩到适合的目录 (我放在~/Document/ 下) ,不需要安装,只要配置systemtap时指定其位置即可。 进入之前解压systemtap的目录,使用下面命令进行配置: ./configure -with-elfutils=~/Document/elfutils-0.156 以这里方法配置之后,你只需要再运行 make install 即完成systemtap的编译安装。如果需要卸载的话,运行 make uninstall。 ...

gomock go install github.com/golang/mock/mockgen@v1.6.0 mockgen -source feeds/feeds.go -destination feeds/mocks/feeds_mock.go -package mocks -source：设置需要模拟 (mock）的接口文件 -destination：设置 mock 文件输出的地方，若不设置则打印到标准输出中 -package：设置 mock 文件的包名，若不设置则为 mock_ 前缀加上文件名 (如本文的包名会为 mock_person）

内核空间, 用户空间; kernel mode/user mode, User space/Kernel space User space & Kernel space 现代操作系统会把内存划分为2个区域，分别为Use space(用户空间) 和 Kernel space(内核空间)。用户的程序在User space执行，系统内核在Kernel space中执行。 用户的程序没有权限直接访问硬件资源，但系统内核可以。比如读写本地文件需要访问磁盘，创建socket需要网卡等。因此用户程序想要读写文件，必须要向内核发起读写请求，这个过程叫system call。 内核收到用户程序system call时，负责访问硬件，并把结果返回给程序。 FileInputStream fis = new FileInputStream("/tmp/test.txt"); byte[] buf = new byte[256]; fis.read(buf); 简单说,Kernel space 是 Linux 内核的运行空间,User space 是用户程序的运行空间。为了安全,它们是隔离的,即使用户的程序崩溃了,内核也不受影响。 Kernel space 可以执行任意命令,调用系统的一切资源；User space 只能执行简单的运算,不能直接调用系统资源,必须通过系统接口 (又称 system call) ,才能向内核发出指令。 str = “my string” // 用户空间 x = x + 2 file.write(str) // 切换到内核空间 y = x + 4 // 切换回用户空间 上面代码中,第一行和第二行都是简单的赋值运算,在 User space 执行。第三行需要写入文件,就要切换到 Kernel space,因为用户不能直接写文件,必须通过内核安排。第四行又是赋值运算,就切换回 User space。 ...