Archive for the ‘Java’ category

G1 日志查看

August 12th, 2019

如果你要在生产环境中使用G1 GC,下面这些跟日志相关的参数是必备的,有了这些参数,你才能排查基本的垃圾回收问题。

使用-XX:GCLogFileSize设置合适的GC日志文件大小,使用-XX:NumberOfGCLogFiles设置要保留的GC日志文件个数,使用-Xloggc:/path/to/gc.log设置GC日志文件的位置,通过上面三个参数保留应用在运行过程中的GC日志信息,我建议最少保留一个星期的GC日志,这样应用的运行时信息足够多的,方便排查问题。

新生代收集

和其他垃圾收集器一样,G1也使用-XX:PrintGCDetails打印出详细的垃圾收集日志,下面这张图是新生代收集的标准流程,我在这里将它分成了6个步骤:

四个关键信息

  • 新生代垃圾收集发生的时间——2016-12-12T10:40:18.811-0500,通过设置-XX:+PrintGCDateStamps参数可以打印出这个时间;
  • JVM启动后的相对时间——25.959
  • 这次收集的类型——新生代收集,只回收Eden分区
  • 这次收集花费的时间——0.0305171s,即30ms

列出了新生代收集中并行收集的详细过程

  • Parallel Time:并行收集任务在运行过程中引发的STW(Stop The World)时间,从新生代垃圾收集开始到最后一个任务结束,共花费26.6ms
  • GC Workers:有4个线程负责垃圾收集,通过参数-XX:ParallelGCThreads设置,这个参数的值的设置,跟CPU有关,如果物理CPU支持的线程个数小于8,则最多设置为8;如果物理CPU支持的线程个数大于8,则默认值为number * 5/8
  • GC Worker Start:第一个垃圾收集线程开始工作时JVM启动后经过的时间(min);最后一个垃圾收集线程开始工作时JVM启动后经过的时间(max);diff表示min和max之间的差值。理想情况下,你希望他们几乎是同时开始,即diff趋近于0。
  • Ext Root Scanning:扫描root集合(线程栈、JNI、全局变量、系统表等等)花费的时间,扫描root集合是垃圾收集的起点,尝试找到是否有root集合中的节点指向当前的收集集合(CSet)
  • Update RS(Remembered Set or RSet):每个分区都有自己的RSet,用来记录其他分区指向当前分区的指针,如果RSet有更新,G1中会有一个post-write barrier管理跨分区的引用——新的被引用的card会被标记为dirty,并放入一个日志缓冲区,如果这个日志缓冲区满了会被加入到一个全局的缓冲区,在JVM运行的过程中还有线程在并发处理这个全局日志缓冲区的dirty card。Update RS表示允许垃圾收集线程处理本次垃圾收集开始前没有处理好的日志缓冲区,这可以确保当前分区的RSet是最新的。
    • Processed Buffers,这表示在Update RS这个过程中处理多少个日志缓冲区。
  • Scan RS:扫描每个新生代分区的RSet,找出有多少指向当前分区的引用来自CSet。
  • Code Root Scanning:扫描代码中的root节点(局部变量)花费的时间
  • Object Copy:在疏散暂停期间,所有在CSet中的分区必须被转移疏散,Object Copy就负责将当前分区中存活的对象拷贝到新的分区。
  • Termination:当一个垃圾收集线程完成任务时,它就会进入一个临界区,并尝试帮助其他垃圾线程完成任务(steal outstanding tasks),min表示该垃圾收集线程什么时候尝试terminatie,max表示该垃圾收集回收线程什么时候真正terminated。
    • Termination Attempts:如果一个垃圾收集线程成功盗取了其他线程的任务,那么它会再次盗取更多的任务或再次尝试terminate,每次重新terminate的时候,这个数值就会增加。
  • GC Worker Other:垃圾收集线程在完成其他任务的时间
  • GC Worker Total:展示每个垃圾收集线程的最小、最大、平均、差值和总共时间。
  • GC Worker End:min表示最早结束的垃圾收集线程结束时该JVM启动后的时间;max表示最晚结束的垃圾收集线程结束时该JVM启动后的时间。理想情况下,你希望它们快速结束,并且最好是同一时间结束。

列出了新生代GC中的一些任务:

  • Code Root Fixup :释放用于管理并行垃圾收集活动的数据结构,应该接近于0,该步骤是线性执行的;
  • Code Root Purge:清理更多的数据结构,应该很快,耗时接近于0,也是线性执行。
  • Clear CT:清理card table

包含一些扩展功能

  • Choose CSet:选择要进行回收的分区放入CSet(G1选择的标准是垃圾最多的分区优先,也就是存活对象率最低的分区优先)
  • Ref Proc:处理Java中的各种引用——soft、weak、final、phantom、JNI等等。
  • Ref Enq:遍历所有的引用,将不能回收的放入pending列表
  • Redirty Card:在回收过程中被修改的card将会被重置为dirty
  • Humongous Register:JDK8u60提供了一个特性,巨型对象可以在新生代收集的时候被回收——通过G1ReclaimDeadHumongousObjectsAtYoungGC设置,默认为true。
  • Humongous Reclaim:做下列任务的时间:确保巨型对象可以被回收、释放该巨型对象所占的分区,重置分区类型,并将分区还到free列表,并且更新空闲空间大小。
  • Free CSet:将要释放的分区还回到free列表。
  • 展示了不同代的大小变化,以及堆大小的自适应调整。
    • Eden:1097.0M(1097.0M)->0.0B(967.0M):(1)当前新生代收集触发的原因是Eden空间满了,分配了1097M,使用了1097M;(2)所有的Eden分区都被疏散处理了,在新生代结束后Eden分区的使用大小成为了0.0B;(3)Eden分区的大小缩小为967.0M
    • Survivors:13.0M->139.0M:由于年轻代分区的回收处理,survivor的空间从13.0M涨到139.0M;
    • Heap:1694.4M(2048.0M)->736.3M(2048.0M):(1)在本次垃圾收集活动开始的时候,堆空间整体使用量是1694.4M,堆空间的最大值是2048M;(2)在本次垃圾收集结束后,堆空间的使用量是763.4M,最大值保持不变。
  • 第6点展示了本次新生代垃圾收集的时间
    • user=0.8:垃圾收集线程在新生代垃圾收集过程中消耗的CPU时间,这个时间跟垃圾收集线程的个数有关,可能会比real time大很多;
    • sys=0.0:内核态线程消耗的CPU时间 –real=0.03:本次垃圾收集真正消耗的时间;

并发垃圾收集

G1的第二种收集活动是并发垃圾收集,并发垃圾收集的触发条件有很多,但是做的工作都相同,它的日志如下图所示:

标志着并发垃圾收集阶段的开始:

  • GC pause(G1 Evacuation Pause)(young)(initial-mark):为了充分利用STW的机会来trace所有可达(存活)的对象,initial-mark阶段是作为新生代垃圾收集中的一部分存在的(搭便车)。initial-mark设置了两个TAMS(top-at-mark-start)变量,用来区分存活的对象和在并发标记阶段新分配的对象。在TAMS之前的所有对象,在当前周期内都会被视作存活的。

表示第并发标记阶段做的第一个事情:根分区扫描

  • GC concurrent-root-region-scan-start:根分区扫描开始,根分区扫描主要扫描的是新的survivor分区,找到这些分区内的对象指向当前分区的引用,如果发现有引用,则做个记录;
  • GC concurrent-root-region-scan-end:根分区扫描结束,耗时0.0030613s

表示并发标记阶段

  • GC Concurrent-mark-start:并发标记阶段开始。(1)并发标记阶段的线程是跟应用线程一起运行的,不会STW,所以称为并发;并发标记阶段的垃圾收集线程,默认值是Parallel Thread个数的25%,这个值也可以用参数-XX:ConcGCThreads设置;(2)trace整个堆,并使用位图标记所有存活的对象,因为在top TAMS之前的对象是隐式存活的,所以这里只需要标记出那些在top TAMS之后、阈值之前的;(3)记录在并发标记阶段的变更,G1这里使用了SATB算法,该算法要求在垃圾收集开始的时候给堆做一个快照,在垃圾收集过程中这个快照是不变的,但实际上肯定有些对象的引用会发生变化,这时候G1使用了pre-write barrier记录这种变更,并将这个记录存放在一个SATB缓冲区中,如果该缓冲区满了就会将它加入到一个全局的缓冲区,同时G1有一个线程在并行得处理这个全局缓冲区;(4)在并发标记过程中,会记录每个分区的存活对象占整个分区的大小的比率;
  • GC Concurrent-mark-end:并发标记阶段结束,耗时0.3055438s
  • 重新标记阶段,会Stop the World
    • Finalize Marking:Finalizer列表里的Finalizer对象处理,耗时0.0014099s;
    • GC ref-proc:引用(soft、weak、final、phantom、JNI等等)处理,耗时0.0000480s;
    • Unloading:类卸载,耗时0.0025840s;
    • 除了前面这几个事情,这个阶段最关键的结果是:绘制出当前并发周期中整个堆的最后面貌,剩余的SATB缓冲区会在这里被处理,所有存活的对象都会被标记;
  • 清理阶段,也会Stop the World
    • 计算出最后存活的对象:标记出initial-mark阶段后分配的对象;标记出至少有一个存活对象的分区;
    • 为下一个并发标记阶段做准备,previous和next位图会被清理;
    • 没有存活对象的老年代分区和巨型对象分区会被释放和清理;
    • 处理没有任何存活对象的分区的RSet;
    • 所有的老年代分区会按照自己的存活率(存活对象占整个分区大小的比例)进行排序,为后面的CSet选择过程做准备;
  • 并发清理阶段
    • GC concurrent-cleanup-start:并发清理阶段启动。完成第5步剩余的清理工作;将完全清理好的分区加入到二级free列表,等待最终还会到总体的free列表;
    • GC concurrent-cleanup-end:并发清理阶段结束,耗时0.0012954s

混合收集

在并发收集阶段结束后,你会看到混合收集阶段的日志,如下图所示,该日志的大部分跟之前讨论的新生代收集相同,只有第1部分不一样:GC pause(G1 Evacuation Pause)(mixed),0.0129474s,这一行表示这是一个混合垃圾收集周期;在混合垃圾收集处理的CSet不仅包括新生代的分区,还包括老年代分区——也就是并发标记阶段标记出来的那些老年代分区。

Full GC

如果堆内存空间不足以分配新的对象,或者是Metasapce空间使用率达到了设定的阈值,那么就会触发Full GC——你在使用G1的时候应该尽量避免这种情况发生,因为G1的Full Gc是单线程、会Stop The World,代价非常高。Full GC的日志如下图所示,从中你可以看出三类信息

  1. Full GC的原因,这个图里是Allocation Failure,还有一个常见的原因是Metadata GC Threshold;
  2. Full GC发生的频率,每隔几天发生一次Full GC还可以接受,但是每隔1小时发生一次Full GC则不可接受;
  3. Full GC的耗时,这张图里的Full GC耗时150ms(PS:按照我的经验,实际运行中如果发生Full GC,耗时会比这个多很多)

基础配置参数中,我这里还想介绍两个:-XX:+PrintGCApplicationStoppedTime-XX:+PrintGCApplicationConcurrentTime,这两个参数也可以为你提供有用的信息,如下图所示:
  1. 记录了应用线程在安全点被暂停的总时间(也就是STW的总时间)
  2. 记录了让所有应用线程进入安全点所花费的总时间
  3. 记录了在两个安全点之间应用线程运行的时间

https://www.redhat.com/en/blog/collecting-and-reading-g1-garbage-collector-logs-part-2?source=author&term=22991

基于Redis的分布式锁的思考

March 31st, 2019

最近在实现一个分布式锁,网上有很多种版本,有的是使用zk实现,有的是使用db,我这里主要使用的是redis。

网上对于基于redis的分布式锁有很多版本,有的实现是错误的,需要进行辨别,我这里主要依赖的是redis的特性,setnx在原本实现里,是没有过期时间的,因此如果遇到系统没有解锁,就会导致死锁,因此网上针对这种问题衍生了很多版本,比如在value里面塞入expireTime来保证是否过期。

但是这种实现方式导致代码很冗余,读起来很晦涩,因此在redis在2.6.12后,set支持setnx的操作,并且支持过期时间,另外该原语是原子的,因此实现分布式锁就两行代码,比网上的实现简化了很多。

Set key to hold the string value. If key already holds a value, it is overwritten, regardless of its type. Any previous time to live associated with the key is discarded on successful SET operation.

Options
Starting with Redis 2.6.12 SET supports a set of options that modify its behavior:

EX seconds — Set the specified expire time, in seconds.
PX milliseconds — Set the specified expire time, in milliseconds.
NX — Only set the key if it does not already exist.
XX — Only set the key if it already exist.
Note: Since the SET command options can replace SETNX, SETEX, PSETEX, it is possible that in future versions of Redis these three commands will be deprecated and finally removed.

Return value
Simple string reply: OK if SET was executed correctly. Null reply: a Null Bulk Reply is returned if the SET operation was not performed because the user specified the NX or XX option but the condition was not met.

在很多不是太注重高并发的场景下还是可以当用的,但使用这种分布式锁还是有些问题的,下面这种场景就是一种情况,

假设锁服务本身是没有问题的,它总是能保证任一时刻最多只有一个客户端获得锁。上图中出现的lease这个词可以暂且认为就等同于一个带有自动过期功能的锁。客户端1在获得锁之后发生了很长时间的GC pause,在此期间,它获得的锁过期了,而客户端2获得了锁。当客户端1从GC pause中恢复过来的时候,它不知道自己持有的锁已经过期了,它依然向共享资源(上图中是一个存储服务)发起了写数据请求,而这时锁实际上被客户端2持有,因此两个客户端的写请求就有可能冲突(锁的互斥作用失效了)。

因此一种方法,称为fencing token。fencing token是一个单调递增的数字,当客户端成功获取锁的时候它随同锁一起返回给客户端。而客户端访问共享资源的时候带着这个fencing token,这样提供共享资源的服务就能根据它进行检查,拒绝掉延迟到来的访问请求(避免了冲突)

 

虽然解决了该问题,但是本质上是因为Redlock的安全性(safety property)对系统的时钟有比较强的依赖,一旦系统的时钟变得不准确,算法的安全性也就保证不了了。Martin在这里其实是要指出分布式算法研究中的一些基础性问题,或者说一些常识问题,即好的分布式算法应该基于异步模型(asynchronous model),算法的安全性不应该依赖于任何记时假设(timing assumption)。

  • 如果是为了效率(efficiency)而使用分布式锁,允许锁的偶尔失效,那么使用单Redis节点的锁方案就足够了,简单而且效率高。Redlock则是个过重的实现(heavyweight)。
  • 如果是为了正确性(correctness)在很严肃的场合使用分布式锁,那么不要使用Redlock。它不是建立在异步模型上的一个足够强的算法,它对于系统模型的假设中包含很多危险的成分(对于timing)。而且,它没有一个机制能够提供fencing token。那应该使用什么技术呢?Martin认为,应该考虑类似Zookeeper的方案,或者支持事务的数据库。

参考

https://blog.csdn.net/jek123456/article/details/72954106

https://redis.io/commands/set

Java序列化与反序列化

August 8th, 2016

最近在对一个大型Java项目进行调试,这个Java程序当点击一个按钮后就会未响应,后来经过调试发现代码中存在大量的io操作,他们将从文件读取的数据存入到HashMap、LinkList中。找到了程序性能瓶颈,我设计一种缓存思路,将这种Object直接写入文件,只要存在我要找的Object文件,我就不会费时费力的重新存入HashMap,而是从Object中读取。

根据查询Java Docs api,我发现一组Interface Serializable,只要class继承了Serializable接口,那么这个类就可以被序列化,因此我把该类中所有的成员变量所在class都继承了Serializable接口。具体读写Object文件的方式和一般文件读取非常类似。

存Object文件:

class T implements Serializable
{
	int i = 10;
	int j = 9;
	double d = 2.3;
	transient int k = 15;
}
....
FileOutputStream fos = new FileOutputStream("...");
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(t);

写Object文件:

FileInputStream fis = new FileInputStream("....");
ObjectInputStream ois = new ObjectInputStream(fis);
T t= (T)ois.readObject();

Java提供了transient 关键字,他的意思就是表明该成员变量不会被序列化,也就是说反序列化后该成员变量保存的值会消失。如果继承了Serializable,我们是无法干预jre对class对象的序列化,所以writeObject、readObject对象一定要顺序相同,因为只有我们知道序列化的内容。

jre为每个序列化的class都赋值了serialVersionUID ,以此来计算反序列化时该值是否相同,不同的话也就意味着该class不能被恢复出来。

The serialization runtime associates with each serializable class a version number, called a serialVersionUID, which is used during deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to serialization. If the receiver has loaded a class for the object that has a different serialVersionUID than that of the corresponding sender’s class, then deserialization will result in an InvalidClassException. A serializable class can declare its own serialVersionUID explicitly by declaring a field named “serialVersionUID” that must be static, final, and of type long:

ANY-ACCESS-MODIFIER static final long serialVersionUID = 42L;

如果我们想控制序列化的时机,那么我们应该让class继承Externalizable接口,Externalizable接口事实上又继承了 Serializable接口,而且在其基础上增加了两个方法:writeExternal()和readExternal()。这两个方法会在序列化和反序列化还原的过程中被自动调用,以便执行一些特殊的操作。

我们可以在writeExternal()和readExternal()中自定义序列化的方式,这样子可以增强灵活性。也就是说每次writeObject时,都会调用WriteExtenal()方法,而在WriteExtenal()方法中我们需要将当前对象的值写入到流中;而每次readObject()时,调用的是默认的构造函数,如果我们不在 readExternal()方法中读取每个成员变量,那么成员变量就是null!

 

参考:

http://www.cnblogs.com/chenfei0801/archive/2013/04/06/3002146.html

解决乱码思路—Java读写文件中遇到的问题

July 26th, 2016

最近在做一个大型Java项目的移植工作,遇到大量字符编码问题,传统的Windows平台主要使用GBK编码,而linux上面为了保持字符的统一性,使用UTF8编码,这个就导致从windows迁移过来的配置文件和资源文件乱码。之前我写过一篇《字符编码浅析》,简单介绍了下这几种编码的不同。

这里我首先解决Linux平台下的乱码问题:如果只是要看一个不同编码的文件,我们可以用vim打开,然后:set fileencoding=utf8  gbk….的方式改变查看文档的编码。如果我们想转换文档编码形式,那么使用以下的命令(将一个GBK编码的文件转换成UTF-8编码):

$enconv -L zh_CN -x UTF-8 filename

文档编码转换完成,这里我从Java的角度阐述如果读写。因为网上关于Java读写的博文足够多,我主要来总结一下:

Java 的IO有两种流的类型:那就是字节流(InputStream、OutputStream)和字符流(Reader、Writer)。我们在读写中文的时候务必使用字符流,因为中文是2个字节组成,如果读取一个字节必然出现问题。

InputStream常用的类是如下,直接对读数据的是节点流,浅色的是处理流,依靠InputStream对数据进行读写,拥有更强大的功能。

20160808200550

OutputStream常用类如下,直接写的是节点流,浅色的是处理流。

20160808200918

二进制读写的时候要使用Stream的方式进行,而读写字符就使用Reader、Writer。

20160808201307

20160808201400

总结一下两种类型,节点流为以下表格,通过这些对象直接对数据源进行读写。

类型 字符流 字节流
File FileReader、FileWriter FileInputStream、FileOutputStream
Memory Array CharArrayReader、CharArrayWriter ByteArrayInputStream、ByteArrayOutputStream
Memory String StringReader、StringWriter
Pipe PipedReader、PipedWriter PipedInputStream、PipedOutputStream
  • 但是节点流提供功能单一,需要使用处理流对其进行拓展,其中尤其是 BufferedReader、BufferedWriter最为常用,先看一个表格:

 

处理类型 字符流 字节流
Buffering BufferedReader、BufferedWriter BufferedInputStream、BufferedOutputStream
 Filtering  FilterReader、FilterWriter FilterInputStream、FilterOutputStream
字节流字符流转换 InputStreamReader、OutputStreamWriter
Object序列化 ObjectInputStream、ObjectOutputStream
数据转换 DataInputStream、DataOutputStream
计数 LineNumberReader LineNumberInputStream
Peeking ahead PushbackReader PushbackInputStream
Print PrintWriter PrintStream
  • BufferedReader和BufferedWriter来读写文件(字符读写,只要不是二进制文件,都可以用字符,字节是给二进制文件使用的),这种方式读写效率最好(而且可以选择想要的字符集),这个主要将数据先缓冲起来,然后一起写入或者读取出来。经常使用的是readLine()方法,一次读取一行数据。其中我们可以根据装饰者模式修改BufferReader和BufferWriter中的类,比如new InputStreamReader(new FileInputStream(…), StandardCharsets.UTF_8),通过这种方式,就可以以UTF-8的方式读取文件,或者以new OutputStreamWriter(new FileOutputStream(“test.txt”), “UTF-8”)写文件

使用方式 FileReader->BufferedReader->readLine、FileWriter->BufferedWriter->write

private static void read() throws FileNotFoundException, IOException {  
        File file = new File("a.txt");// 指定要读取的文件  
        // 获得该文件的缓冲输入流  
        BufferedReader bufferedReader = new BufferedReader(new FileReader(file));  
        String line = "";// 用来保存每次读取一行的内容  
        while ((line = bufferedReader.readLine()) != null) {  
            System.out.println(line);  
        }  
        bufferedReader.close();// 关闭输入流  
    }  
private static void write() throws IOException {  
        File file = new File("a.txt");// 指定要写入的文件  
        if (!file.exists()) {// 如果文件不存在则创建  
            file.createNewFile();  
        }  
        // 获取该文件的缓冲输出流  
        BufferedWriter bufferedWriter = new BufferedWriter(new FileWriter(file));  
        bufferedWriter.write("你好世界");  
        bufferedWriter.newLine();
        bufferedWriter.write("hello world");  
        bufferedWriter.flush();// 清空缓冲区  
        bufferedWriter.close();// 关闭输出流  
    }  

与他类似的就是BufferedInputStream和BufferedOuputStream,用这两个读取二进制文件,不同的在于读取的是二进制文件。

FileInputStream ——>BufferedInputStream -> read、FileOutputStream->BufferedOutputStream->write

        // 指定要读取文件的缓冲输入字节流  
        BufferedInputStream in = new BufferedInputStream(new FileInputStream("a.jpg"));  
        File file = new File("b.jpg");  
        if (file != null) {  
            file.createNewFile();  
        }  
        // 指定要写入文件的缓冲输出字节流  
        BufferedOutputStream out = new BufferedOutputStream(new FileOutputStream(file));  
        byte[] bb = new byte[1024];// 用来存储每次读取到的字节数组  
        int n;// 每次读取到的字节数组的长度  
        while ((n = in.read(bb)) != -1) {  
            out.write(bb, 0, n);// 写入到输出流  
        }  
        out.close();// 关闭流  
        in.close();  

有的时候我们还要使用File对象,这个时候可以查看FileInputStream、FileOutputStream、FileReader、FileWriter的构造方法。类似于FileReader(File file)。

字符流到字节流的转换也很重要,类似于:

InputStreamReader isr = new InputStreamReader(System.in);
BufferedReader br = new BufferedReader(isr);
    String s = null;
    try {
      s = br.readLine();
...

OutputStreamWriter osw = new OutputStreamWriter(
           new FileOutputStream("...."));
osw.write("mircosoftibmsunapplehp");

Java中io类太多了,有时候容易眼花,不知道用哪个,这个时候只要记住字符流和字节流的异同,合理使用类,并查询java api即可。

参考:

http://blog.csdn.net/dangnianmingyue_gg/article/details/47361323