快过年的时候（2月17日），我还在火车上，从内部微信群里得到消息，说网上有传闻，刘江峰将要离职。还没来得及去搜索相关，又有人留言说余总已经发微博证实了这个传闻，赶紧去微博查看余总的博客，果然，和蔼可亲的江总要离开我们了，根据华为规定，离职需要提前一个月申请，完成工作交接，流程结束，才能离开，刘总将在公司呆到3月份。赵明将成为新一任荣耀掌门人。 华为公司一直追求的，个别人的离开，不会影响公司的大方向。所以任总才会选择一个团队来接班，当然刘江峰的离职不会造成荣耀部门以及华为终端的大方向和决定，但是新领导上任势必会引起内部一定结构的调整，和当前的布局。还是希望华为荣耀能健康稳定的发展，祝福刘总。
MWC是世界移动通信大会的英文缩写，其前身是3GSM展，由GSM Association发起并举办，于每年年初(通常为2月)举行，它是全球通信领域最具规模和影响的展会，众多从事通信产业的全球知名企业都将出席这一展会。2008年，3GSM大会正式更名为MWC大会。 MWC2014 华为发布了首款平板手机跨界之作荣耀X1，荣耀X1主打的是屏幕大，同时可以打电话，而且有3G 4G版本，后面又出了爱奇艺版本，囊括国内外电视剧，好莱坞影库，实属一个看片神器，一举打败小米平板 《你是选择小米平板还是华为荣耀X1？》 MWC2015在今年2月底开幕，华为2015年将要退出的旗舰机型，从时间安排上好像都不和本次展览吻合，根据2014年的情况，荣耀X1是2014年华为首款手机，那荣耀X2作为华为2015年首款机型，在本次展览上发布是有极大可能性的。 据媒体报道的关于荣耀X2的配置如下： CPU：麒麟925 内存3G 屏幕7寸，1080p 移动联通双4G 外观金属机身 售价依然1999 荣耀从去年7月就开始有传闻《7.22华为有新品 或为大屏荣耀X2》，并且有金属骨架曝光《CES2015国际消费类电子产品展览会上荣耀可能会发布X2?》，千呼万唤始出来，希望这次MWC2015，我们能看到荣耀平板手机延续经典之作-荣耀X2的真容。
配置tomcat的gzip压缩功能之后，配置有个compressionMinSize选项，表示压缩响应的最小值，只有当响应报文大小大于这个值的时候才会对报文进行压缩。但是有时候你会发现这个配置并不起作用，貌似只要客户端加了Accept-Encoding: gzip, deflate，响应就是压缩的，无论响应报文体有多大，这是怎么回事呢？ 查看tomcat源码，关于压缩条件控制的地方：org.apache.coyote.http11.AbstractHttp11Processor类中： // Check if sufficient length to trigger the compression long contentLength = response.getContentLengthLong(); if ((contentLength == -1) || (contentLength > compressionMinSize)) { // Check for compatible MIME-TYPE if (compressableMimeTypes != null) { return (startsWithStringArray(compressableMimeTypes, response.getContentType())); } } 可以看到，tomcat判断是否压缩的的依据是根据你响应里的Content-length来的，如果没有Content-length或者Content-length大于compressionMinSize就进行压缩。如果你的报文小于compressionMinSize，却被压缩了，那就是你的响应报文中并不含有Content-length。 Content-length可以在往外写响应流之前手动设置，如果你不设置的话，在关闭响应流的时候，如果你的响应体没超过tomcat默认缓存区大小8*1024，它也会帮你设置Content-lenth，如果超过了缓存区大小，tomcat会以Transfer-Encoding: chunked的形式返回响应。 所以如果你的设置compressionMinSize的没有生效，很有可能是 你的设置的compressionMinSize超出了tomcat的缓冲区大小，响应默认是chunked的形式返回的，这种情况是肯定压缩的。这种情况，还是有部分响应<8k的响应是不压缩的。 如果你的响应无论什么大小都被压缩了，那很有可能就是你在代码中使用了OutputStream.flush(),或者PrintWriter.flush()。使用flush()的意思是响应开始往外写了，Content-length已经来不及写了，tomcat会默认使用Transfer-Encoding: chunked形式帮你返回消息，响应肯定是要被压缩的。
java的控制台输入是很局限的，我们仅仅可得到它的输入，对于输入的过程是很难操控的，所以当我们想写一个人性化的输入体验的时候，是比较难实现的。还好java中有种jni的技术，它允许Java代码和其他语言写的代码进行交互。 Jline就是一个使用了C/C++实现的java类库，它可以让你更方便的处理控制台输入。 引入Jline，使用下面的maven配置 <dependency> <groupId>jline</groupId> <artifactId>jline</artifactId> <version>2.9</version> </dependency> 我们平常处理输入一般是这样的： BufferedReader br = new BufferedReader(new InputStreamReader(System.in)); String line = null; do { line = br.readLine(); if(line != null) { //todo } } while(line!=null && !line.equals("exist")) 在使用了Jline之后，一样的书写形式： ConsoleReader reader = new ConsoleReader(); String line = null; do { line = reader.readLine("input>"); if(line != null) { //TODO } } while(line!=null && !line.equals("exist")) 你便拥有了一个比较友好的输入体验了。它可以实现光标的移动，通过上下方向键切换历史命令等操作。 如果你希望有更强大的自动补全功能。你可以给ConsoleReader 设一个jline.console.completer.Completer接口实现类 public interface Completer int complete(String buffer, int cursor, List candidates); } 其中buffer是当前用户输入的内容，cursor表示光标的位置，candidates表示你想补全的候选项。返回值很重要，表示你要再哪个位置补全你的内容 假设用户的输入是ls my xxxxxx 目前用户的光标在my后面，你想帮用户补全为myfoler或者myfile。你要这么写： ...
前提 cassandra的根据分区key的操作是很快的，这也是它的优势，但是它的多条件查询是很弱的，特别是如果你有删除操作的话，就更坑爹了。cassandra的删除操作，实际上并不是真的删除，它是执行的插入操作，插入的数据叫做tombstone（墓碑)，记录了被删除记录的信息和删除时间。当你根据条件查询的时候，如果它会把满足条件的记录查询出来，包括tombstone。然后过滤掉删除的记录，再把结果返回给你。 现象 如果你的表mykeyspace.t_table有3个副本，主键是(a,b,c) 。你插入4000条数据(a=1)，然后再删除掉3999条，你再根据a=1去查询，你会在cassandra的日志中发现一条警告日志. WARN [ReadStage:18926] 2015-02-05 07:18:02,869 SliceQueryFilter.java Read 1 live and 11997 tombstoned cells in mykeyspace.t_table (see tombstone_warn_threshold).... 这个警告信息是根据你的cassandra.yaml里配置的tombstone_warn_threshold决定的。也就是说它搜索了11997=3999*3条数据，才搜到一个1个live。这就是墓碑的危害。当你删除的数据更多的时候。到达配置项tombstone_failure_threshold的值，这次查询就失败了。你会看到下面的ERROR日志。 ERROR [ReadStage:219774] 2015-02-04 00:31:55,713 SliceQueryFilter.java (line 200) Scanned over 100000 tombstones in mykeyspace.t_table; query aborted (see tombstone_fail_threshold) ERROR [ReadStage:219774] 2015-02-04 00:31:55,713 CassandraDaemon.java (line 199) Exception in thread Thread[ReadStage:219774,5,main] java.lang.RuntimeException: org.apache.cassandra.db.filter.TombstoneOverwhelmingException at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1916) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: org.apache.cassandra.db.filter.TombstoneOverwhelmingException at org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:202) 真实的数据实实在在的被删除，发生在两个时期： 第一个时期是新的SSTable文件生成的时候。而且它只删除gc_grace_seconds之前插入的tombstone。 gc_grace_seconds是表结构的一个额外参数，可以通过alter table进行修改。所以说如果你的某个节点挂了，挂的时间超过gc_grace_seconds。可能导致删除的数据又出现了。 第二个时期就来自日常的Nodetool repair操作。每个gc_grace_seconds周期内至少repair一遍。 解决 普通repair nodetool repair基本语法是这样的： nodetool -h host repair [keyspace] [cfnames] 它会修复keyspace.cfnames这个表分区主键token值落在这个节点上的数据(包括master和slave数据)。等你把所有的节点repair一遍， 如果你有三个副本，你相当于repair了三遍数据，所以这个时间会很长。 ...
HTTP协议中关于压缩传输的规定 第一：客户端传输到服务器请求中带有：Accept-Encoding:gzip, deflate 字段，向服务器表示，客户端支持的压缩格式（gzip或者deflate)，如果不发送改消息头，服务器是不会压缩的。 第二：服务端在收到请求之后，如果发现请求头中含有Accept-Encoding字段，并且支持该类型的压缩，就对响应报文压缩之后返回给客户端，并且携带Content-Encoding:gzip消息头，表示响应报文是根据该格式压缩过的。 第三：客户端接收到请求之后，先判断是否有Content-Encoding消息头，如果有，按该格式解压报文。否则按正常报文处理。 服务端实现报文压缩 一般http容器都有配置实现压缩的，不需要代码实现 [nginx实现压缩，在nginx.conf中配置] #开启缓存 gzip on; #启动压缩的最小报文大小 gzip_min_length 1k; #压缩所使用的缓存 gzip_buffers 4 16k; #压缩等级1表示最快，9表示最好 gzip_comp_level 2; #压缩支持的content-Type类型 gzip_types text/plain text/javascript application/x-javascript text/css text/xml application/xml application/xml+rss; [apache实现压缩，在httpd.conf中配置] #启动deflate模块 LoadModule deflate_module modules/mod_deflate.so #配置压缩等级和压缩类型 DeflateCompressionLevel 6 AddOutputFilterByType DEFLATE text/plain text/html text/css text/javascript application/x-javascript [tomcat配置压缩] 参考《Tomcat配置gzip提高js文件下载速度》 客户端实现报文解压缩 [浏览器] 浏览器在访问一个网站的时候，默认都是带着Accept-Encoding:gzip, deflate头信息的，当收到响应的时候，如果是压缩的格式，也会自然解压。这一般不需要我们关系的。 [JAVA代码实现] java中访问一个url，一般使用apache的HttpClient，加上它的连接池管理，参考《JAVA的那些池子》 获得一个HttpClient实现类对象： HttpClient httpClient = new DefaultHttpClient(connectionManager, params); 使用它去发送http请求。这个httpclient发出去的http请求是默认不带Accept-Encoding:gzip, deflate头信息的。自然返回的响应也不会是压缩的。如果你希望实现接收压缩，进行解压缩的功能，你可以使用org.apache.http.impl.client.DecompressingHttpClient，它只是对Httpclient进行了一个包装。构造方法如下 HttpClient httpClient = new DefaultHttpClient(connectionManager, params); httpClient = new DecompressingHttpClient(httpClient); 后面就和之前发http请求，一样使用这个httpClient了，对压缩解压缩的功能，对你写代码而言是完全透明的。
华为2015年新旗舰机型Mate8,一直是大家热议的对象，多次曝光谍照，配置，发布时间，定价等等。 没想到有的媒体竟然拿到了华为2015年所有旗舰机型的配置和发布时间表，不知真假： 根据这次贴吧曝光的华为2015年新机终端表格显示，荣耀品牌将会有四款新机主攻中低端市场，而华为品牌则是三款机型抢占中高端市场。 消费者最关心的机型应该是荣耀旗舰-荣耀7，以及高端商务旗舰-Mate8。 从图上看这次荣耀7相较荣耀6,在基础配置上包括CPU\内存\屏幕方法没有多大改进。通过荣耀6和Mate8上的成功，华为此次应该在外观、照相、续航等方面在荣耀7上进行提升。 例如金属机身设计，双摄像头不知是否会继续保留，使用新的麒麟930芯片，应该在功耗上会有进一步提升，当然这只是目前可以预见的，产品出来的时候肯定还会有别的亮点。否则一部新旗舰的所有特点在未发布前几个月就曝光了，实在是不应该的。 华为的三7四G战略，Mate7 和 P7都是很成功的，唯独G7不温不火，虽然G7的外观设计和Mate8类似，但是配置就低了，屏幕720p，没有指望识别，只有背部和边框是金属的，售价和荣耀6、6Plus是一样的，属于中端机型，消费者在这个价位有更多的选择，G7自然不是那么成功。这次华为改为演进自己的D系列，之前只出过两款D1、D2，都主张高性能，主打高端。这次直接跃升到D8，自然有质的飞跃，就目前这张表上看，性能就已经很强劲了，2K屏，麒麟950，4G内存 金属机身，蓝宝石屏幕，哇塞~ 让我们期待华为2015年一波又一波的新品发布会吧。
这两天余总和小米关于2K屏幕的微博论战中，我们可以感受到华为和小米他们更看重的是什么，它们追求的是什么。 余总的微博： 余总的微博很浅显易懂，客观的描述。就是说在小尺寸屏幕下，2k屏幕相比于1080p，并不能带来多大的体验提升。也有微博用户@酷玩强哥 从理论角度分析了，在6寸以下屏幕上人眼是很难分辨出1080P和2k屏幕之间的差别的。 相反高分辨率肯定会带来更多的电能损耗，而且小米Note的电池只有3000mA，肯定造成续航方面的牺牲。 再看小米方面的的回复： 不是一味的嘲讽，就是混淆概念，转移话题，小米Note在5.7寸屏幕上就使用2K分辨率的屏幕，而且电池没有提升，余总说的就是这个2k屏幕带来的续航问题，小米方面没有直接从正面回答这个问题，一味的强调2K是顶配，或者说人家夏普的屏幕多么多么好。小米各个微博帐号同时发力，狂轰乱炸，试图掩盖这个事实。我们不再次佩服小米方面的营销能力。 从两家企业这次骂战可以看到两家企业的不同追求和核心价值观： 华为讲究的是技术创新，不断的通过技术创新，改进手机性能，质量，用户体验，发热，续航。这也是华为一直强调的核心价值观：“以客户为中心,以奋斗者为本” 而小米考虑的又是什么呢？怎么样把最顶配的器件捏合在一起，让它赚足眼球，在器件量产之前提升人气，在量产之后，价格下降再出货。小米没有任何一代手机的设计工艺是从上一代产品中继承来的。雷军的小米发布会更多的是介绍里面的元器件有什么什么优点，频率多么高，性能多么好，那里面到底有多少小米自己的科技成分呢？ 一个科技企业的核心竞争力是不断的技术创新和质量追求。从而获取丰厚的利润回报，然后再投入不断的技术创新，从而进入良性循环。一个企业没有自己的核心竞争力，它是走不远的。不可否认小米把世界上最顶级的配置捏合在一起，让更多的用户用到了更好的屏幕，更快的CPU，更大的内存的手机。但是这些都是可以模范的，例如锤子手机，一加手机，什么大可乐手机，它们都可以开发出一套基于安卓的ROM, 拿到最顶配的器件组装成一部手机。相反它们无法生产出自己的CPU，无法达到最佳的省电技术，很好的控制手机温度稳定不发烫，保证稳定强劲的信号。而这些只有华为这样的企业可以。 我支持余总，支持华为，支持荣耀。
本博客在上线之初，就受垃圾评论的骚扰，有一种wordpress评论机器人，每天都自动寻找wordpress站点，进行自动评论，每天都收到大量这样的垃圾评论： 我不想关闭评论功能，或者是只允许注册之后评论，因为我自己的博客，没必要，我也不想开放注册功能的。我一开始的解决方法是屏蔽这些IP，见文章：《如何屏蔽恶意访问IP》 可是屏蔽了一部分IP，过几天又有新的ip出现。目前已经屏蔽了数个IP段： 199.30.24.* 199.30.25.* 112.111.189.* 112.111.191.* 112.111.184.* 但是老是这样屏蔽也不是办法，有可能把正常用户的ip给屏蔽了。今天才想到了这个问题，在防止垃圾评论上，屏蔽IP太不专业了，垃圾评论是机器人所为，而在计算机的世界里，验证码才是自动区分计算机和人类行为的专业行为。 好了，搜索CAPTCHA，安装一个验证码wordpress插件，设置一下，ok了，再也不用担心垃圾评论的问题了。
在cassanda的官方驱动cassandra-driver-core-2.1.3.jar之前，创建表、修改表、创建索引操作，只能通过拼CQL语句，然后通过session去执行的方式。可能会经常导致语法格式错误。 在最新版的驱动cassandra-driver-core-2.1.3.jar中，提供了一种更方便的对表的修改方式。类似于用于增删改查操作的com.datastax.driver.core.querybuilder.QueryBuilder类，它提供了一个com.datastax.driver.core.schemabuilder.SchemaBuilder类用于对表的操作。 这个类可以构建几乎所有关于对表的操作，这里举例常用的操作： 先引入jar包： <dependency> <groupId>com.datastax.cassandra</groupId> <artifactId>cassandra-driver-core</artifactId> <version>2.1.3</version> </dependency> 然后你就可以像写cql语句一样，流畅的使用SchemaBuilder了。其中省略了session的生成，可以参考《java实现cassandra的增删改查》 //创建表 Create createTbale = SchemaBuilder.createTable("mykeyspace", "mytable") .addPartitionKey("pk1", DataType.cint()) .addColumn("col1", DataType.text()) .addColumn("col2", DataType.bigint()); session.execute(createTbale); //增加一列 SchemaStatement addColumn = SchemaBuilder.alterTable("mykeyspace", "mytable") .addColumn("col3") .type(DataType.cdouble()); session.execute(addColumn); //删除一列 SchemaStatement dropColumn = SchemaBuilder.alterTable("mykeyspace", "mytable") .dropColumn("col2"); session.execute(dropColumn); //修改一列 SchemaStatement alterColumn = SchemaBuilder.alterTable("mykeyspace", "mytable") .alterColumn("col1") .type(DataType.cdouble()); session.execute(alterColumn); //列更改名字 SchemaStatement renameColumn = SchemaBuilder.alterTable("mykeyspace", "mytable") .renameColumn("col1") .to("col4"); session.execute(alterColumn); //增肌索引 SchemaStatement createIndex = SchemaBuilder.createIndex("idx_col4") .onTable("mykeyspace", "mytable") .andColumn("col4"); session.execute(createIndex); //删除索引 Drop dropIndex = SchemaBuilder.dropIndex("mykeyspace", "idx_col4") .ifExists(); session.execute(dropIndex); //删除表 Drop dropTable = SchemaBuilder.dropTable("mykeyspace", "mytable") .ifExists(); session.execute(dropTable);
今日早上习惯性的在百度site了一下自己的网站，惊喜的发现本站在百度也有站点信息了，截图如下： 不仅仅如此，另外一个小站也有了站点信息： 众所周知，百度推出site显示一个站点的备案等信息的功能，也就几个月时间，应该是为了识别出稳定可靠，有价值，健康的网站，以便把那些临时的，违法的网站剔除掉。在之初只有大型的门户网站以及一些出名的网站才会显示站点信息，慢慢扩大范围，据猜测，只有建站年限、收录量、访问量等一些参数满足了百度的相关条件才会被收录。 本站建站有一年有余，虽然不是每天都有更新，但也是持续到现在，本站百度收录量从只收录首先到现在三四百页，访问量从个位数的PV发展到每天近200PV，我想这是让百度信任的首要条件，其次就是本站从建站初期就使用百度统计、后来加入了百度联盟广告，这也是贴近百度的一种方式，我的第二个站也被百度显示了站点信息，但是访问量并不大，想想可能就是用了百度统计，百度联盟广告的原因，或者是沾了第一个网站的光了。 写博客是我的个人爱好，也是为了分享，博客被更多的人看到，总是高兴的，谢谢大家浏览我的博客，也希望其中的内容能对你所帮助。
一直在找一个bash实现的多线程，虽然这个方法看着不怎么高明，但是比那个fifo的写法，看着明白点。这里面也限制了最多线程数，类似于线程池，记录在此，以备后用。 #!/bin/bash MAX_THREAD_NUM=10; thread_pids=() #执行线程 function hello_thread(){ echo "print $1" sleep 5; } #检查是否有完成的线程，把pid剔除调 function check_current_thread(){ if [ ${#thread_pids[@]} -ne 0 ]; then for pid_idx in ${!thread_pids[*]}; do pid_val=${thread_pids[$pid_idx]} kill -s 0 $pid_val &>/dev/null || unset thread_pids[$pid_idx] done thread_pids=("${thread_pids[@]}") fi; } for i in {1..100}; do #如果当前执行的线程数少于10个，就加一个任务 if [ ${#thread_pids[@]} -lt $MAX_THREAD_NUM ]; then hello_thread $i & thread_pids=("${thread_pids[@]}" "$!"); else sleep 1; check_current_thread; fi done #等待最后的任务结束 while [ ${#thread_pids[@]} -ne 0 ]; do check_current_thread; sleep 1; done;
昨日小米发布红米2，相当于小米2的造型再翻出来，加上个4G的噱头，1G的内存，着实没啥亮点。 售价699，在这个价格附近，在荣耀里面可以随便挑出几款手机与之对阵。 小米是低端路线走到底了，据悉后面要发布一款399元的机器。 为了阻击小米，华为荣耀积极应战，华为荣耀品牌走的就是中低端路线。 工信部上显示了一款编号20141110的华为手机，如果不出意外它就是那款应对小米399元的新机型。 传闻也是399元（也可能是398元哟） 从照片上看，这款机型属于荣耀系列，前黑后白，四周圆润。 据传闻这款机型： 支持TD-LTE/TD-SCDMA/GSM网络，支持双卡双待，内存为1GB，分辨率为1280*720，预计售价399元。另外前后置摄像头估计为500万和200万。 如果这款手机发布，估计是市面上价格最便宜的4G手机了吧。
最近从cassandra 2.0.8升级到2.1.2，在考察2.1.2的时候，发现了一个2.1.2版的一个bug，一直怀疑是java驱动的原因，后来发现只要满足特定条件，就可以重现，用cqlsh客户端也可以。 bug重现步骤: 首先创建keyspace space1和space2. 在space1里创建一个表table3 在space2里创建两个表table1,table2 在table3里插入一条记录 删除表table1 删除table3插入的那条记录 删除表table2 再根据主键，在tbale3里查询，会发现之前那条记录并未删除。 CREATE KEYSPACE space1 WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 3}; CREATE TABLE space1.table3(a int, b int, c text,primary key(a,b)); CREATE KEYSPACE space2 WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 3}; CREATE TABLE space2.table1(a int, b int, c int, primary key(a,b)); CREATE TABLE space2.table2(a int, b int, c int, primary key(a,b)); INSERT INTO space1.table3(a,b,c) VALUES(1,1,'1'); drop table space2.table1; DELETE FROM space1.table3 where a=1 and b=1; drop table space2.table2; select * from space1.table3 where a=1 and b=1; you will find that the row (a=1 and b=1) in space1.table3 is not deleted ...
使用slf4j配合log4j打日志已经使用很长时间了，已经习惯了log4j的properties文件配置了。 具体参考：《slf4j、log4j 的使用》 虽然从log4j换到logback也不费劲，性能上提升在常规业务上也不是多么明显，但是作为处女座的我，还是想从log4j换到logback来。logback log4j 和slf4j都是同一作者。根据作者宣称的： slf4j的出现是为了替代commons-logging logback的出现是为了替代log4j，用作者的话，叫：“picking up where log4j leaves off" logback比log4j会有更高的性能，和更多的功能支持。 如果你之前是使用slf4j+log4j的组合打日志的话，你只要换个jar包和配置文件就可以了。 之前需要的jar包是： <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.7.7</version> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> <version>1.7.7</version> </dependency> <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.16</version> </dependency> 现在需要的jar包是： <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.7.7</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>1.1.2</version> </dependency> logback-classic的pom会自动引入logback-core包 一般都是sl4j和log4j一起使用的，很少有人直接用log4j的logger打日志。如果你已经那样做了，也不必要修改代码。 只要引入log4j-over-slf4j的桥接包，删掉log4j包，以前log4j打印的日志，会自动桥接到slf4j进而使用logback的logger打印日志。 <dependency> <groupId>org.slf4j</groupId> <artifactId>log4j-over-slf4j</artifactId> <version>1.7.7</version> </dependency> 配置文件使用XML格式配置：logback.xml 基本的示例： <!--60秒检查一次配置文件是否有修改，即时生效--> <configuration scan="true" scanPeriod="60 seconds" debug="false"> <property name="ROOT_LOG_PATH" value="/disk/log" /> <!--设置变量--> <appender name="STDOUT"> <!-- 打印到控制台的appender --> <encoder> <pattern>%d{HH:mm:ss.SSS}%-5level %logger{36}-%msg%n</pattern> </encoder> </appender> <appender name="FILE"> <!--打印到文件，20M滚一个，最多20个--> <file>test.log</file> <rollingPolicy> <fileNamePattern>${ROOT_LOG_PATH}/my.log.%i</fileNamePattern> <maxIndex>20</maxIndex> </rollingPolicy> <triggeringPolicy> <maxFileSize>20MB</maxFileSize> </triggeringPolicy> <encoder> <pattern>%d{HH:mm:ss.SSS}%-5level %logger{36}-%msg%n</pattern> </encoder> </appender> <root level="DEBUG"> <!--根日志--> <appender-ref ref="FILE" /> </root> <!--设置包com.zhaoyanblog的日志级别, 设置是否也打印一份到它的父logger（这里是root）设置的appender里--> <logger name="com.zhaoyanblog" level="INFO" additivity="false"> <appender-ref ref="STDOUT"/> </logger> <!--设置包com.zhaoyanblog.test的日志级别--> <logger name="com.zhaoyanblog.test" level="ERROR" /> </configuration> 以上是对logback的简单配置，平常足够使用了，如果你已经习惯了log4j的properties形式的配置文件，想使用更高效的logback，又不想去学习logback的配置形式。logback为你这种懒人提供了一个log4j.properties在线自动转logback.xml的页面： http://logback.qos.ch/translator/