BlogJava-X-Spirit-随笔分类-Java SE

【Tech Details】【转】有关Java SPI机制

X-Spirit — Sat, 03 Mar 2012 03:34:00 GMT

@import url(http://www.blogjava.net/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);

转自：http://blog.csdn.net/fenglibing/article/details/7083071

一个服务(service)通常指的是已知的接口或者抽象类，服务提供方就是对这个接口或者抽象类的实现，然后按spi标准存放到资源路径META-INF/services目录下，文件的命名为该服务接口的全限定名。如有一个服务接口com.test.Service，其服务实现类为com.test.ChildService，那此时需要在META-INF/services中放置文件com.test.Service，其中的内容就为该实现类的全限定名com.test.ChildService，有多个服务实现，每一行写一个服务实现，#后面的内容为注释，并且该文件只能够是以UTF-8编码。
这种实现方式，感觉和我们通常的开发方式差不多，都是定义一个接口，然后子类实现父类中定义的方法，为什么要搞这么一套标准以及单独搞一个配置文件？这种方式主要是针对不同的服务提供厂商，对不同场景的提供不同的解决方案制定的一套标准，举个简单的例子，如现在的JDK中有支持音乐播放，假设只支持mp3的播放，有些厂商想在这个基础之上支持mp4的播放，有的想支持mp5，而这些厂商都是第三方厂商，如果没有提供SPI这种实现标准，那就只有修改JAVA的源代码了，那这个弊端也是显而易见的，也就是不能够随着JDK的升级而升级现在的应用了，而有了SPI标准，SUN公司只需要提供一个播放接口，在实现播放的功能上通过ServiceLoad的方式加载服务，那么第三方只需要实现这个播放接口，再按SPI标准进行打包成jar，再放到classpath下面就OK了，没有一点代码的侵入性。

以下是找到的几篇文章：

1、http://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html，这个是官方的文档，有对service的详细介绍，包括规范以及一个简单的示例，这个是学习SPI必须看的文档；

注：http://docs.oracle.com/javase/1.4.2/docs/guide/jar/jar.html#Service%20Provider，这个是1.4中对Service Provider的介绍，加载服务是通过sun.misc.Service进行加载的，这个也有相应的示例，照做就OK；

2、Java的SPI机制：http://www.2cto.com/kf/201012/79868.html，这个是国人写的一篇示例文章，也挺不错，里面也有一个简单的示例；

3、Developing a Service Provider using Java API(Service Provider Interface)：http://blog.csdn.net/fenglibing/article/details/7083526，这篇文章是转的alexa发表在blogspot上面的，也是一个开发SPI的示例，有兴趣的也可以看看；

4、Add Mp3 capabilities to Java Sound with SPI：http://www.javaworld.com/javaworld/jw-11-2000/jw-1103-mp3.html，这是一个比较老的例子，基于jdk1.3的，因为在jdk1.3的时候还没有支持mp3格式，只支持AU, AIF, MIDI, and WAV等格式，也是一个值得参考的示例。

我这边也写了一个简单得不能够再简单的示例，源码可以这里下载：http://download.csdn.net/detail/fenglibing/3939882

最后很重要一点：

如果想要覆盖某个Provider，可以在对应的META-INF/services的配置文件中加上新service的一行，或者也可以写在另一个有依赖关系的jar包中，只要和原来的Provider命名不同即可。加载顺序上可以考虑使用@Priority注解来调整加载的优先级。

@import url(http://www.blogjava.net/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);

X-Spirit 2012-03-03 11:34 发表评论

【Effective】Logging最佳实践

X-Spirit — Sat, 12 Feb 2011 11:55:00 GMT

#意识

ASAP (As Soon As Possible)原则

当线上出现诡异问题，

当你意识到靠现有的日志无法定位问题时，

当现象难以在你的开发环境重现时，

请不要执著于枯坐肉眼看代码，因为：一）不一定是你代码逻辑问题，可能是脏数据造成的，是老业务数据造成的，是分布式环境造成的，是其他子系统造成的；二）线上业务处于不稳定中，条件不允许问题定位无限期。

此时，请立即在问题相关的调用链条上，一次性：

在函数的入口和出口打印日志，同时打印输入、输出参数
catch(){……}里打印stacktrace，同时打印try块中关键变量的值（避免你发现某个异常是问题第一原因，却不知道是什么变量传入导致的）
与其他模块交互的接口入口处打印输入参数，

即，解决线上问题归根结底要靠log、a lot of log output！

在logging的力度上切勿犹犹豫豫，我们的工程师习惯于吝啬地找两个函数打印日志、打包部署一把、没看出来、再找几个函数打印、再部署、等着现象重现再观察、……，一来二去时间流逝，闲庭信步，从客服知道的小事故变成了全国皆知的大事故。

所以，再强调一遍：在你的调用链条上，逐层调用的函数入口和出口都打印详细日志，不怕多只怕少，然后部署，等待现象重现，毕其功于一役！

我们要记录什么？

1）完成某项操作所需的时间

通过它可以跟踪为什么系统响应变慢或者太快

处理完一个incoming request所耗费的时间，精确到毫秒
执行数据库查询的时间
从磁盘或者存储介质获取数据的时间
等等

2）异常和堆栈跟踪

3）Sessions

知道一个问题是由谁引起的非常重要，因此在日志中使用会话标识符就变得必不可少。它可以简单到是一个 IP 地址或者是一个更复杂的 UUID，只要能区分不同的请求者就足够。

4）版本号

#工具

推荐的Java Logging框架

1）log4j：我们的配置是，log4j.appender.CONSOLE.layout.ConversionPattern= [%-d{yyyy-MM-dd HH\:mm\:ss.SSS}] [%p] [%c] [%m]%n；%p是日志优先级，%c是类目名，%m是输出信息，%n是回车换行符。

2）logback：log4j创建人Ceki Gülcü后续推出了SLF4J+logback。SLF4J(Simple Logging Facade for Java)作为commons-logging的替代，为各种logging APIs提供了一个简单的统一接口，使得最终用户能够在部署的时候配置所希望的logging APIs的实现。logback胜在性能，据称“某些关键操作，比如判定是否记录一条日志语句的操作，其性能得到了显著的提高。这个操作在logback 中需要3纳秒，而在 log4j 中则需要30纳秒。 logback 创建记录器（logger）的速度也更快：13毫秒，而在 log4j 中需要23毫秒。更重要的是，它获取已存在的记录器只需94纳秒，而 log4j 需要2234纳秒，时间减少到了1/23。跟java.util.logging(JUL)相比性能提高也是显著的”。

#配置

不要随便从网上找一个log4j的配置文件，请确认你理解每一个配置项

我们既然输出日志，自然期望在面对“这个问题是否从过去几天开始出现？”这样的疑问时，不至于发现你的rollingPolicy错误设置导致只能看到最近几小时的日志，或者日志发生时间没有精确到毫秒。

#理念

可用grep抽取的日志：独立的行！

我们总是希望能用grep处理日志文件。这意味着：一个日志条目永远不应该跨多行，除非你是堆栈打印。

我们会用grep问日志什么问题呢？如：

用手机号13910******下单的顾客最近三天内都来自于哪些IP？
浏览地址是****?from=kfapi的顾客，但referral却是搜索引擎域名，最近三天有多少次？
最近一周内，订单中心执行的所有事务，耗时最长的一次是多长时间？
××××的接口是否真的于18:00发送了一个请求，我们收到的参数是什么？

确保你的日志能回答这样的问题。

不同关注领域写不同的日志文件

当访问和调用极其频繁，有时候你会发现把你的工程里什么信息都打印到一个日志文件里，会让你看得头昏脑胀。

最简单的示范就是Apache的访问日志和错误日志是分开的。

同样，你也可以把更加安静的事件（偶尔出现）与更加喧闹的事件分开存储。

如，对外的开放平台可以打印三种日志文件：connection log（建立链接和关闭链接，附带接入参数），message log（内部调用链），stacktrace log（异常的堆栈打印）。

#具体实现

至少精确到毫秒

日志必须包含时间戳，精确到至少毫秒级。

如果只是记录到秒级，我们曾明知代码因缺乏并发控制而产生BUG，却只能郁闷地看着精确到秒级的日志。

对Java来说，最好配置为：yyyy-MM-dd/HH:mm:ss.SSS。

请尽可能打印明确的会话标识

日志条目里打印一个会话标识（A certain session identifier），当有许多并发请求打过来时，你就能基于此字段过滤 client 了。比如，我们日志会补充打印一个浏览器 cookies 里种下的 UUID 。

log4j的isDebugEnabled判断

如果打印信息是常量字符串或简单字符串拼接，那么不需要if ( log.isDebugEnabled() )。

如果你拼装的动作比较耗资源，请用if ( log.isDebugEnabled() )。

如有可能，请将性能数据标准化输出

这样更方便grep或hadoop做性能数据抽取和挖掘，从而能很轻松地转换为图形监控。

比如，订单中心的性能数据格式为：树枝标志当前节点起始时间 [当前节点持续时间, 当前节点自身消耗时间, 在父节点中所占的时间比例]

哪些位置需要部署性能检测点

（1）访问数据库的dao层；

（2）访问外部资源的ext层；

（3）访问mq的方法；

（4）等等，一切不在你自己负责的工程掌握的部分（外部），或一切你认为自己工程的性能危险点，都需要加入性能监控日志。

#Sample

一个好的启动日志

打印了应用的版本号，客户端的会话标识，关键步骤的执行时长。

一个好的堆栈跟踪日志

本文首发于旁观者-郑昀的55最佳实践系列，链接：http://www.cnblogs.com/zhengyun_ustc/archive/2012/12/15/logging_bp.html

X-Spirit 2011-02-12 19:55 发表评论

Java 多线程同步问题的探究（五、你有我有全都有—— ThreadLocal如何解决并发安全性？）【更新重要补疑】

X-Spirit — Sat, 24 Apr 2010 05:36:00 GMT

摘要: 前面我们介绍了Java当中多个线程抢占一个共享资源的问题。但不论是同步还是重入锁，都不能实实在在的解决资源紧缺的情况，这些方案只是靠制定规则来约束线程的行为，让它们不再拼命的争抢，而不是真正从实质上解决他们对资源的需求。在JDK 1.2当中，引入了java.lang.ThreadLocal。它为我们提供了一种全新的思路来解决线程并发的问题。但是他的名字难免让我们望文生义：本地线程？ ... 阅读全文

X-Spirit 2010-04-24 13:36 发表评论

Java 多线程同步问题的探究（四、协作，互斥下的协作——Java多线程协作（wait、notify、notifyAll））

X-Spirit — Sat, 24 Apr 2010 05:35:00 GMT

摘要: Java监视器支持两种线程：互斥和协作。前面我们介绍了采用对象锁和重入锁来实现的互斥。这一篇中，我们来看一看线程的协作。举个例子：有一家汉堡店举办吃汉堡比赛，决赛时有3个顾客来吃，3个厨师来做，一个服务员负责协调汉堡的数量。为了避免浪费，制作好的汉堡被放进一个能装有10个汉堡的长条状容器中，按照先进先出的原则取汉堡。如果容器被装满，则厨师停止做汉堡，如果顾客发现容器内的汉堡吃完了，... 阅读全文

X-Spirit 2010-04-24 13:35 发表评论

Java 多线程同步问题的探究（三、Lock来了，大家都让开【2. Fair or Unfair? It is a question...】）

X-Spirit — Sat, 24 Apr 2010 05:34:00 GMT

摘要: 阅读全文

X-Spirit 2010-04-24 13:34 发表评论

Java 多线程同步问题的探究（三、Lock来了，大家都让开【1. 认识重入锁】）

X-Spirit — Sat, 24 Apr 2010 05:33:00 GMT

摘要: 阅读全文

X-Spirit 2010-04-24 13:33 发表评论

Java 多线程同步问题的探究（二、给我一把锁，我能创造一个规矩）

X-Spirit — Sat, 24 Apr 2010 05:32:00 GMT

摘要: 阅读全文

X-Spirit 2010-04-24 13:32 发表评论

Java多线程同步问题的探究（一、线程的先来后到）

X-Spirit — Sat, 24 Apr 2010 05:31:00 GMT

摘要: 阅读全文

X-Spirit 2010-04-24 13:31 发表评论

【Effective】JVM 调优参数说明

X-Spirit — Tue, 16 Mar 2010 14:42:00 GMT

@import url(http://www.blogjava.net/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);

内部服务参数配置：

JAVA_OPTS="-server -XX:+UseParNewGC -Xms1024m -Xmx2048m -XX:MaxNewSize=128m -XX:NewSize=128m -XX:PermSize=96m -XX:MaxPermSize=128m -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:CMSInitiatingOccupancyFraction=1 -XX:+CMSIncrementalMode -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=20000 -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:CMSIncrementalDutyCycleMin=10 -XX:CMSIncrementalDutyCycle=30 -XX:CMSMarkStackSize=8M -XX:CMSMarkStackSizeMax=32M"

前端应用参数配置：

JAVA_OPTS="-server -Xmx4096m -Xms4096m -Xmn480m -Xss256k -XX:PermSize=128m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=8 -XX:CMSFullGCsBeforeCompaction=0
-XX:+UseCMSCompactAtFullCollection -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=7 -XX:GCTimeRatio=19
-Xnoclassgc -XX:+DisableExplicitGC -XX:+UseParNewGC -XX:-CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=70 -XX:SoftRefLRUPolicyMSPerMB=0"

参数说明：

-Xmx1280m：设置JVM最大可用内存为1280m。最大可设为3550m。具体应用可适当调整。

-Xms1280m：设置JVM初始内存为1280m。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。

-Xmn480m：设置年轻代大小为480m。整个堆大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。

-Xss256k：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。

-XX:PermSize=64m：指定 jvm 中 Perm Generation 的最小值。这个参数需要看你的实际情况。可以通过jmap 命令看看到底需要多少。

-XX:MaxPermSize=128m：指定 Perm Generation 的最大值

-XX:+UseConcMarkSweepGC：设置并发收集器

-XX:ParallelGCThreads=8：配置并行收集器的线程数，即：同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。

-XX:CMSFullGCsBeforeCompaction=0：由于并发收集器不对内存空间进行压缩、整理，所以运行一段时间以后会产生“碎片”，使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。

-XX:+UseCMSCompactAtFullCollection：打开对年老代的压缩。可能会影响性能，但是可以消除碎片。

-XX:SurvivorRatio=8：每个survivor space 和 eden之间的比例。

-XX:MaxTenuringThreshold=7：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概率。

-XX:GCTimeRatio=19：设置垃圾回收时间占程序运行时间的百分比，公式为1/(1+n)。

-Xnoclassgc：禁用类垃圾回收，性能会有一定提高。

-XX:+DisableExplicitGC：当此参数打开时，在程序中调用System.gc()将会不起作用。默认是off。

-XX:+UseParNewGC：设置年轻代为并行收集。可与CMS收集同时使用。

-XX:-CMSParallelRemarkEnabled：在使用 UseParNewGC 的情况下 , 尽量减少 mark 的时间。

-XX:CMSInitiatingOccupancyFraction=70：指示在 old generation 在使用了 70% 的比例后 , 启动 concurrent collector。

-XX:SoftRefLRUPolicyMSPerMB=0：每兆堆空闲空间中SoftReference的存活时间。

@import url(http://www.blogjava.net/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);

X-Spirit 2010-03-16 22:42 发表评论