BlogJava-xylz,imxylz-随笔分类-J2EE

Java 8 入门/新特性

imxylz — Tue, 15 Oct 2013 16:33:00 GMT

2013/09/05 已经发布了JDK 8的M8 Developer Preview版本。在M7(2013/06/13) 所有新特性已经封版， M8 作为开发者预览版，基本上可用，可用Oracle网站下载。按照计划 GA(General Availability)版本应该在2014年3月份发布，如果顺利正式版估计和GA版本相同，也就是说在明年3月份就正式使用JDK 8了。

这次JDK 8 一共带来了55个新特性，目前所有API应该都已经冻结，正在进行零bug测试。这次更新的力度比JDK 6/JDK 7都要大，延期了几次，也非常令人期待。我个人准备花费几个月的学习时间，努力跟上Java 8的发布节奏。当然由于对Java 7不太熟悉，因此同时也学习下Java 7的API。

目前支持JDK 8的IDE有：

Netbeans 7.4
IDEA 12
非官方的Eclipse, 官方需要到明年Java 8正式发布以后

并非所有JDK 8的特性IDE都能支持，因此需要随时更新IDE以便获得更好的开发环境，推荐使用IDEA。

Java 8 新特性入门

时间表
Lambda
流式操作 – Stream API
接口默认方法 – Default Method
日期和时间 – Date & Time (JSR 310)
集合扩展 – Collections API
并发操作 – Concurrency API additions
IO/NIO 扩展 – IO/NIO API additions
反射和注解更新 – Reflection and annotation changes
Base64
其它各种更新 – Other additions

Java 7 新特性入门

字符串在switch中的使用
try-with-resources 自动释放资源
泛型实例创建的类型推断
多异常catch操作
文件API扩展
集合API更新
并发编程API更新
Unicode 6.0的支持
JDBC 4.1 支持 RowSet 1.1

[更新时间: 2013/10/16]
[原文地址：Java 8 入门/新特性]

imxylz 2013-10-16 00:33 发表评论

随机选择集合的子元素集合

imxylz — Sat, 17 Aug 2013 09:44:00 GMT

我需要一个从集合N中随机选择M个子元素的算法。当然最好的办法是将集合打乱顺序，然后从中选择前M个元素即可。 Java中现成的API可以使用：

java.util.Collections.shuffle(List)

此算法非常简单，循环N次，每次长度减少1，随机获取其中一个元素，然后交换其对称元素。

public static void shuffle(List list, Random rnd) {
    int size = list.size();
    if (size < SHUFFLE_THRESHOLD || list instanceof RandomAccess) {
        for (int i=size; i>1; i--)
            swap(list, i-1, rnd.nextInt(i));
    } else {
        Object arr[] = list.toArray();

        // Shuffle array
        for (int i=size; i>1; i--)
            swap(arr, i-1, rnd.nextInt(i));

        // Dump array back into list
        ListIterator it = list.listIterator();
        for (int i=0; i             it.next();
            it.set(arr[i]);
        }
    }
}

有点意思的swap函数

public static void swap(List list, int i, int j) {
final List l = list;
l.set(i, l.set(j, l.get(i)));
}

其实我们的需求很简单，在基本不变的集合中，多次重复随机获取其子集，至于子集是否有序或者随机不重要的，重要的是原集合中的每个元素都有相似的概率出现在子集合中。

考虑到性能以及并发访问（多线程）的需要，我想到了一个简单的算法：

给定N个元素集合，从中选择M(0

随机选择索引K(0<=K
取有效元素N(k-i),N(k+i) 加入未满子集M
i+=1, 重复(2) 直到子集M已满
终止

这样取出来的元素虽然和原始集顺序有一定的关系，但是每个元素在子集里出现的概率相当，满足结果要求。最后生成的算法如下：

public static  List randomList(List views, int max) {

    final int size = views.size();
    int index = RandomUtils.nextInt(size);
    //
    List ret = new ArrayList(max);
    int low = index - 1, high = index;
    while (max > 0 && (low >= 0 || high < size)) {
        if (low >= 0 && max-- > 0) {
            ret.add(views.get(low));
        }
        if (high < size && max-- > 0) {
            ret.add(views.get(high));
        }
        low--;
        high++;
    }
    return ret;
}

此算法满足如下特点：

足够快
线程安全（原始集合不变）
子元素出现概率相当（未经数学证明

另外，stackoverflow上也有一些参考链接：

Select a random N elements from List in C#

http://mcherm.com/permalinks/1/a-random-selection-algorithm
http://stackoverflow.com/questions/4702036/take-n-random-elements-from-a-liste

[ 原文地址 http://imxylz.com/blog/2013/08/14/select-a-random-sublist-from-list-in-java/ ]

imxylz 2013-08-17 17:44 发表评论

Crack JRebel 5.3.1

imxylz — Wed, 26 Dec 2012 04:02:00 GMT

JRebel 在热部署上真是神器，目前支持Windows 32/64、Linux 32/64、Mac OS X等操作系统，这可以从jrebel里面的jni动态链接库可以看出来。

我一直使用5.1.0版本的jrebel，是social免费版本的。social版本会在启动时连接jrebel服务器（myrebel)获取license，同时会将一些热部署的次数、节约时间、性能等日志提交到远程服务器。
最近中国网络抽风，连接jrebel服务器特别慢，导致每次启动的时候都需要10s以上的时间才能得到服务器的响应（加上自动更新检测）。最为一个技术控，很显然，我不能忍受这种行为。

只好研究如何破解它。
从4.0开始jrebel的混淆机制做得非常棒，基本上无法进行反编译修改了。好在jrebel比较厚道，一直兼容旧版本的license检测机制，翻出我2008年写的破解工程，顺利解决了5.1.0版本。
然后下载最新的5.1.2（20121217）版本，尝试了下居然没有成功。太囧了。这是一个小版本，为何改动如此大？

打开debug日志后发现，根本就没有加载jrebel.jar里面的License文件。反编译源码看了下，果然，从5.1.2版本开始不再加载jrebel.jar里面的license文件了，该从用户主目录，jrebel安装目录等获取license文件。这样就没法通过一个jar包分发jrebel了。
将jrebel.lic拷贝到用户主目录的.jrebel目录即可。

~ $ ls ~/.jrebel/jrebel.lic
/Users/adyliu/.jrebel/jrebel.lic

来两张截图。

下载地址

4.0 http://www.blogjava.net/xylz/archive/2011/06/12/352109.html
5.1.0 /Files/xylz/jrebel.jar.zip
5.1.2 /Files/xylz/jrebel-5.1.2.zip
5.2.0 jrebel-5.2.0-crack.zip
5.2.2 jrebel-5.2.2-crack.zip
5.3.0 jrebel-5.3.0-crack.zip
5.3.1 jrebel-5.3.1-crack.zip
5.3.2 jrebel-5.3.2-crack.zip

Updated 2013/03/25
JRebel更新到5.2.0版本，所以可以放出一个低版本（我一直使用）5.1.2。5.1.3就暂时不去解决了。

Updated 2013/04/17
JRebel 更新到5.2.2版本，所以可以放出一个低版本5.2.0。

Updated 2013/06/06
JRebel 更新到5.3.0版本，所以可以放出一个低版本5.2.2。

Updated 2013/07/12
JRebel 更新到5.3.1版本，所以可以放出一个低版本5.3.0。

Updated 2013/09/15
最新版本的下载地址在：http://www.blogjava.net/xylz/archive/2013/09/15/404098.html

PS:
吐槽下，JRebel支持的功能越来越多，导致本身越来越大了，版本5.x已经快9M了！！！

关键词： JRebel 5.3.1 crack, JRebel 5.3.0 crack, JRebel 5.2.2 crack, JRebel 5.2.0 crack, JRebel 5.1.2 crack,JRebel 5.1.0 crack, JRebel 5.x crack

imxylz 2012-12-26 12:02 发表评论

一次简单却致命的错误

imxylz — Thu, 15 Mar 2012 10:30:00 GMT

线上服务器负载过高发生了报警，同事找我求救。
我看到机器的负载都超过20了，查看java进程线程栈，找到了出问题的代码。

下面是其代码片段，实际情况错误处理比这更坏。

1 package demo;
2
3 import java.io.BufferedReader;
4 import java.io.InputStream;
5 import java.io.InputStreamReader;
6 import java.net.HttpURLConnection;
7 import java.net.URL;
8 import java.net.URLConnection;
9 import org.apache.commons.lang.StringUtils;
10
11 /**
12  * @author adyliu (imxylz#gmail.com)
13  * @since 2012-3-15
14  */
15 public class FaultDemo {
16
17     /**
18      * @param args
19      */
20     public static void main(String[] args) throws Exception {
21         final String tudou = "http://v.youku.com/v_playlist/f17170661o1p9.html";
22
23         URL url = new URL(tudou);
24         HttpURLConnection conn = (HttpURLConnection) url.openConnection();
25         conn.connect();
26         try {
27             InputStream in = conn.getInputStream();
28             BufferedReader br = new BufferedReader(new InputStreamReader(in, "utf-8"));
29             StringBuilder buf = new StringBuilder();
30             String line = null;
31             while ((line = br.readLine()) != null) {
32                 if (StringUtils.isNotEmpty(buf.toString())) {
33                     buf.append("\r\n");
34                 }
35                 buf.append(line);
36             }
37             //do something with 'buf'
38
39         } finally {
40             conn.disconnect();
41         }
42
43     }
44
45 }
46

思考下，这段代码有什么致命问题么？（这里不追究业务逻辑处理的正确性以及细小的瑕疵）
.
..
...
现在回来。
我发现线程栈里面的线程都RUNNABLE在32行。
这一行看起来有什么问题呢？StringBuilder.toString()不是转换成String么？Apache commons-lang里面的StringUtils.isNotEmpty使用也没问题啊？
看代码，人家的逻辑其实是判断是否是第一行，如果不是第一行那么就增加一个换行符。

既然CPU在这里运行，那么就说明这个地方一定存在非常耗费CPU的操作，导致CPU非常繁忙，从而系统负载过高。
看详细堆栈，其实CPU在进行内存的拷贝动作。
看下面的源码。
java.lang.StringBuilder.toString()

  public String toString() {
        // Create a copy, don't share the array
    return new String(value, 0, count);
    }

接着看java.lang.String的构造函数：

  public String(char value[], int offset, int count) {
        if (offset < 0) {
            throw new StringIndexOutOfBoundsException(offset);
        }
        if (count < 0) {
            throw new StringIndexOutOfBoundsException(count);
        }
        // Note: offset or count might be near -1>>>1.
        if (offset > value.length - count) {
            throw new StringIndexOutOfBoundsException(offset + count);
        }
        this.offset = 0;
        this.count = count;
        this.value = Arrays.copyOfRange(value, offset, offset+count);
    }

看出来了么？
问题的关键在于String构造函数的最后一行，value并不是直接指向的，而是重新生成了一个新的字符串，使用系统拷贝函数进行内存复制。

java.util.Arrays.copyOfRange(char[], int, int)

  public static char[] copyOfRange(char[] original, int from, int to) {
        int newLength = to - from;
        if (newLength < 0)
            throw new IllegalArgumentException(from + " > " + to);
        char[] copy = new char[newLength];
        System.arraycopy(original, from, copy, 0,
                         Math.min(original.length - from, newLength));
        return copy;
    }

好了，再回头看逻辑代码32行。

if (StringUtils.isNotEmpty(buf.toString())) {
buf.append("\r\n");
}

这里有问题的地方在于每次循环一行的时候都生成一个新的字符串。也就是说如果HTTP返回的结果输入流中有1000行的话，将额外生成1000个字符串（不算StringBuilder扩容生成的个数）。每一个字符串还比前一个字符串大。

我们来做一个简单的测试，我们在原来的代码上增加几行计数代码。

  int lines =0;
    int count = 0;
    int malloc = 0;
    while ((line = br.readLine()) != null) {
        lines++;
        count+=line.length();
        malloc += count;
        if (StringUtils.isNotEmpty(buf.toString())) {
            buf.append("\r\n");
        }
        buf.append(line);
    }
    System.out.println(lines+" -> "+count+" -> "+malloc);

我们记录下行数lines以及额外发生的字符串拷贝大小malloc。
这是一次输出的结果。

1169 -> 66958 -> 39356387

也就是1169行的网页，一共是66958字节（65KB），结果额外生成的内存大小（不算StringBuilder扩容占用的内存大小）为39356387字节（37.5MB)!!!
试想一下，CPU一直频繁于进行内存分配，机器的负载能不高么？我们线上服务器是2个CPU 16核，内存24G的Redhat Enterprise Linux 5.5，负载居然达到几十。这还是只有访问量很低的时候。这就难怪服务频繁宕机了。

事实上我们有非常完善和丰富的基于Apache commons-httpclient的封装，操作起来也非常简单。对于这种简单的请求，只需要一条命令就解决了。

String platform.utils.HttpClientUtils.getResponse(String)
String platform.utils.HttpClientUtils.postResponse(String, Map)

即使非要自造轮子，处理这种简单的输入流可以使用下面的代码，就可以很好的解决问题。

InputStream in =
    ByteArrayOutputStream baos = new ByteArrayOutputStream(8192);
    int len = -1;
    byte[] b = new byte[8192];//8k
    while ((len = in.read(b)) > 0) {
        baos.write(b, 0, len);
    }
    baos.close();//ignore is ok
    String response =  new String(baos.toByteArray(), encoding);

当然了，最后紧急处理线上问题最快的方式就是将有问题的代码稍微变通下即可。

  if (buf.length() > 0) {
        buf.append("\r\n");
    }

这个问题非常简单，只是想表达几个观点：

团队更需要合作，按照规范来进行。自造轮子不是不可以，但是生产环境还是要限于自己熟悉的方式。
即使非常简单的代码，也有可能有致命的陷阱在里面。善于思考才是王道。
学习开源的代码和常规思路，学习解决问题的常规做法。这个问题其实非常简单，熟悉输入输出流的人非常熟练就能解决问题。

imxylz 2012-03-15 18:30 发表评论

Spring Framework 3.1 Reference CHM

imxylz — Wed, 08 Feb 2012 08:41:00 GMT

自己制作的CHM文件，基于SpringFramework最新版本3.1.0.RELEASE。不喜欢的可以使用原版的HTML或者PDF版本。其实PDF版本排版就挺好的。

去掉了发生错误的javascript（网络原因，你懂的），索引排序重命名，稍微排版了下。

没有改动任何内容。毫无疑问，这是英文版的，因为没有人翻译。

截图如下。

Spring Framework 3.1 Reference CHM
SpringFramework3.1-Reference_en.chm

imxylz 2012-02-08 16:41 发表评论

编程语言大战

imxylz — Tue, 06 Dec 2011 03:25:00 GMT

摘要: 刚看到这个月的编程语言排行榜，很显然java的霸主地位很快就会在发达国家被挤掉，C语言依然是王者（想想上个月自己买的两个C语言的书，冷汗直流）。看来我迟早要回归C，这才是真正的王道。

非常令人吃惊的是C++语言依然不够坚挺，由于Windows 7/Windows 8的发力，C#很快就会抢占C++的市场，估计很快就会将C++从前三名中挤下去。

iPhone/iPad的热销让Object C继续火热，前十的位置还是可以持续很久的，这一点毋庸置疑。移动设备开发的高端人才现在是高薪难求，如果有时间我也要继续关注下。阅读全文

imxylz 2011-12-06 11:25 发表评论

处理Zookeeper的session过期问题

imxylz — Mon, 05 Dec 2011 05:57:00 GMT

摘要: Zookeeper客户端和服务端维持一个长连接，每隔10s向服务端发送一个心跳，服务端返回客户端一个响应。这就是一个Session连接，拥有全局唯一的session id。Session连接通常是一直有效，如果因为网络原因断开了连接，客户端会使用相同的session id进行重连。由于服务端保留了session的各种状态，尤其是各种瞬时节点是否删除依赖于session是否失效。
Session失效问题

通常客户端主动关闭连接认为是一次session失效。另外也有可能因为其它未知原因，例如网络超时导致的session失效问题。在服务端看来，无法区分session失效是何种情况，一次一旦发生session失效，一定时间后就会将session持有的所有watcher以及瞬时节点删除。
而对于Zookeeper客户端而言，一旦发生失效不知道是否该重连，这涉及到watcher和瞬时节点问题，因此Zookeeper客户端认为，一旦发生了seesion失效，那么就认为客户端死掉了。从而所有操作都不能够进行。参考 How should I handle SESSION 阅读全文

imxylz 2011-12-05 13:57 发表评论

享受热部署的好处

imxylz — Fri, 17 Jun 2011 01:25:00 GMT

你还在为频繁部署服务器而烦恼么？

亲，试试jrebel吧。更多jrebel的介绍参考这里http://www.zeroturnaround.com/jrebel/。

啊？免费版只能使用30天？花钱？十个人的团队使用一年的企业版License是2891$！你没看错，是真真正正的美帝国的钱！

好吧，我等穷人使用不起，只好“自己动手/丰衣足食”。

这里提供了一个完整功能的企业版，免费大甩送了，有木有!!!

http://www.blogjava.net/xylz/archive/2011/06/12/352109.html

怎么使用，最简单方式,在resin的启动文件，例如httpd.sh中增加：

Resin 3.1+版本：

exec $JAVA_EXE -javaagent:/opt/apps/resin/jrebel4.0-crack.jar -jar ${RESIN_HOME}/lib/resin.jar $*

Resin 3.0-版本：

args=”-J-javaagent:/opt/apps/resin/jrebel4.0-crack.jar“

Tomcat？Jetty? Jboss? WebLogic? WebSphere? Maven? Eclipse? And More?

OK，参考这里文档吧：http://www.zeroturnaround.com/reference-manual/

亲，不要钱的，试试吧！

有木有更简单，更NB的热部署秘籍啊？

有的，亲！

如果你的Linux x86 (x86_64位目前没有)的glibc是2.4+版本，试试dcevm吧！Windows 32/64位同样有相应的版本啊！

imxylz 2011-06-17 09:25 发表评论

Crack JRebel 4.0，无需重启JVM，热部署解决方案

imxylz — Sat, 11 Jun 2011 16:24:00 GMT

http://dl.dropbox.com/u/22951342/jrebel.jar www.zeroturnaround.com最近又接触到一点WEB应用，想到Resin服务器重启需要花费比较多的时间（Spring将WEB服务搞得越来越复杂，越来越臃肿了），所以又想到了08年那时候用JavaRebel了。一段时间不用人家居然改名为JavaRebel了。
如果不熟悉的可以搜索下JRebel/JavaRebel，这里是官方网站：

www.zeroturnaround.com。
最近刚发布了4.0版本，功能更强大，配置也更加简单了。价格不菲。
官方提供30天试用版，可以先体验下再决定是否购买。

看到里面的代码混淆让我很崩溃，没有深入研究混淆后的运行机制。比如下面居然有两个名称相同，参数相同，但是返回值不同的静态方法，不知是如何执行的。
public static void a(String s)和 public static String a(String)，以及
private static void c()和private static String c()。
猜测是在运行的时候自己进行JVM指令的执行。这样的代码反编译后都不知道怎么写回去，想到崩溃，因为两个方法居然都有地方调用了。

zhangthe9 提供了一个4.0的破解版，我很好奇，咨询了下，居然还是以前的RSA签名算法。

好吧，翻出08年写的JavaRebel 2.0-M1的破解程序，重新生成一个license文件，修改公钥，替换license文件，居然运行正常。这么多年了，签名算法和步骤居然一点都没变，嗯，人家真执着！
当然是无限制版，所有功能可用，也没有时间限制。

#############################################################

JRebel 4.0 (201105311152)
with Enterprise Add-On! (see http://jrebel.com/enterprise)
(c) Copyright ZeroTurnaround OU, Estonia, Tartu.

Over the last 1 days JRebel prevented
at least 0 redeploys/restarts saving you about 0 hours.

This product is licensed to www.imxylz.info
for unlimited number of developer seats on site.
== Cracked by imxylz (imxylz#gmail.com) from JavaRebel 2.0-M1, 2008 ==

#############################################################

伟大领袖毛主席，指引我们向前进！
jrebel cracked by imxylz
伟大领袖毛主席，指引我们向前进！
jrebel cracked by imxylz
JRebel: Reloading class 'ReloadClass'.change
伟大领袖毛主席，指引我们向前进！
class!

破解思路很简单，替换公钥，使用自己私钥生成签名License文件。
如果想屏蔽版本更新提示，有以下几种思路：
（1）修改调用更新坚持的类（难道有点大，因为混淆比较严重，不容易反编译）
（2）修改更新服务器的地址，将http://update.zeroturnaround.com/jrebel/地址修改，可以使用二进制工具直接修改字符串，比如我就将update改为updatt，无法解析域名就不能获取最新版本了。
（3）增加-Drebel.disable_update=true参数即可。（这种方法最简单）。

当然了，为了“保护知识产权”，不会将破解文件放出来，有需求的可以留言联系。（所谓的“计算机条例”是允许为了学习、研究而进行相关逆向工程的，哈哈）。

好吧，架不住国人的热情，这里是下载地址，需要翻X，你懂得！

http://dl.dropbox.com/u/22951342/jrebel.jar

[关键字： JRebel, JavaRebel, JRebel Crack, JRebel License, JavaRebel License]

imxylz 2011-06-12 00:24 发表评论

当Ajax遭遇GBK编码 (完全解决方案)

imxylz — Fri, 10 Jun 2011 15:46:00 GMT

摘要: 当Ajax遇到GBK/GB2312，我们恨不能将所有项目的编码统一改为UTF-8。显然这个做法，成本太高了。下面给出了一个完善的解决方案。此方案不仅仅限于Ajax提交数据，也适用于普通访问请求。阅读全文

imxylz 2011-06-10 23:46 发表评论

CRACK xmind 3.2.1 PRO功能

imxylz — Thu, 07 Apr 2011 15:56:00 GMT

摘要: 迫于很多项目的格式都是xmind的，最近从mindmanager迁移到xmind了，发现免费的东西国人还是很喜欢的，要是将收费功能免费化就更好了。本来想支持下国产软件，一看那PRO版价格，算了，还是老老实实用免费的吧。
xmind介绍点击这里和这里。思维导图介绍点击这里。
好吧，我努力下，将最新的xmind【截止2011/4/7版本】pro版本功能挖掘出来。下面是一个智能截图[pro]功能的使用截图。我使用了其它一些PRO功能发现都可以使用，包括导出，但是没有完全使用所有PRO功能，如果还有请告知吧。
另外，这不需要帐户进行登录就可以使用所有PRO功能。阅读全文

imxylz 2011-04-07 23:56 发表评论

深入浅出 Java Concurrency (34): 线程池 part 7 线程池的实现及原理 (2)

imxylz — Fri, 11 Feb 2011 15:48:00 GMT

摘要: 这一节中我们将详细讨论线程池是如何执行一个任务的，尤其是如何处理线程池的大小、核心大小、最大大小、任务队列等之间的关系的。阅读全文

imxylz 2011-02-11 23:48 发表评论

一个身份证号码的基础验证

imxylz — Wed, 05 Jan 2011 02:00:00 GMT

摘要: 本着开发的原则，既然用到了别人家的东西，所以决定公开出来，也算是给别人一个参考。阅读全文

imxylz 2011-01-05 10:00 发表评论

深入浅出 Java Concurrency (29): 线程池 part 2 Executor 以及Executors

imxylz — Tue, 21 Dec 2010 15:32:00 GMT

摘要: Java里面线程池的顶级接口是Executor，但是严格意义上讲Executor并不是一个线程池，而只是一个执行线程的工具。真正的线程池接口是ExecutorService。
下面这张图完整描述了线程池的类体系结构。阅读全文

imxylz 2010-12-21 23:32 发表评论

Ibatis 2.x日志记录（SQL调试）分析

imxylz — Sun, 05 Dec 2010 07:17:00 GMT

摘要: 最近的项目使用的是旧的ibatis2.x版本，有时候为了方便调试，想输出SQL执行的语句和参数。我记得应该有某些logger的日志级别修改为DEBUG就可以看到。当然为了方便可以直接在log4j（如果使用log4j的话）的root日志级别修改为DEBUG，并且输出appender的接受级别修改为DEBUG就可以了。这样是可以看到日志信息（SQL/参数）等，但是同时也输出了过多的其它logger信息，显然在一个稍微大一点的系统里面debug的信息应该都是非常多的，不说别的，光是spring的日志就够好多页了。
为了解决过多的日志，翻出ibatis源码，看了下。ibatis的执行流程大致是这样的。阅读全文

imxylz 2010-12-05 15:17 发表评论

Java常见疑惑和陷阱（PPT）

imxylz — Fri, 03 Dec 2010 08:13:00 GMT

本来是打算小范围内讨论的，话题也比较小，后来听说人多了，临时拼凑些材料。话题过大后重点就放在讲解上，其实这里面讲解的东东还是挺多的。以后有时间会将并发完整整理一次。

Java常见疑惑和陷阱

View more presentations from xylz.

imxylz 2010-12-03 16:13 发表评论

【广告】淘宝招聘高级JAVA开发工程师

imxylz — Tue, 02 Nov 2010 08:09:00 GMT

职位名称：高级JAVA开发工程师

招聘数量：若干（我们组估计还需要6~8人）

工作地点：北京（注意不是杭州）

岗位职责：

参与淘宝新业务产品系统设计与编码工作，负责业务项目的开发和维护，负责各项目的设计，制定和评审各种技术规范。

具体要求：

. 计算机相关专业大学本科以上学历，具有扎实的计算机基础理论知识；【只需要学校好点就行，面试的时候少被相关人士歧视下】

. 三年以上使用Java语言进行网站开发的经验；【两年也考虑吧，一年左右的就算了，不想带人学习】

. 熟悉Web JSP,Servlet,Java Bean,JMS,EJB,Jdbc开发，熟悉J2EE规范；【估计每一个人都会这么说】

. 熟悉基于数据库的设计和开发；【这是啥玩意儿需求】

. 熟悉Linux操作系统和大型数据库；【评论：这个是扯淡，基本上用不着，淘宝划分的太细了】

. 工作认真，细心，有条理；积极性高，求知欲强；具有较强的沟通能力及团队合作精神；【虚的，没啥意思】

. 有招聘等行业开发经验者优先；【不是必须，但是会做相关工作】

. 深入了解设计模式和项目管理经验者优先；【不是必须，有一点讨论起来容易点】

=====

以上是官方说明，先补充几点：

（1）熟悉淘宝webx框架的绝对优先

（2）目前系统还很烂，所以技术比较初级，但是需要ibatis和velocity相关技术。

（3）如果有一些设计思想或者经历就更好了（比如UML/架构/模型等）

其它的就算了，有亮点先说明。

~~联系方式: 暂时不招了~~

PS: 有意向的先发个简历过来，不想发简历的也可以先用邮件沟通下。

有兴趣的可以先看看《技术文化和惨淡命运 —— 怀念中国雅虎》，有个心理准备，仅供参考。

【最后更新时间：2011.3.30 11:11】

imxylz 2010-11-02 16:09 发表评论

这是JVM的Bug么？谁遇到下面的情况？

imxylz — Wed, 11 Aug 2010 16:54:00 GMT

我在CentOS release 5.3 (Final)遇到一种情况：

一个类的所有public static final字段中，按照定义的从上往下顺序，到一个字段为止，此字段的上面的所有字段都能访问，此字段下面（包括子字段）都不能访问。

具体是这样的：resin环境下一个jsp访问一个类的某个字段，在web请求此jsp的时候被告知编译jsp失败，原因是：cannot find symbol。并指明了此类的哪一个字段。具体分析后发现此字段的上面所有字段都可以访问，此字段的下面字段（包括自己）都不能访问。但是诡异的是，在jsp中使用Class.getField()或者getFields()遍历是可以拿到此字段的，并且此字段是完整的，可用的。

也就是说JVM实例化了一个类，完成了所有字段的初始化，但是在将所有字段设置为对外可见时失败了，导致一部分字段对外是不可见的，但是此类却成功初始化，并对外可用了。这里所说的对外可见不是说字段设置为非public，而是类外根本就看不到，因为如果是非public的话会得到一个访问修饰符不可见的错误，但是现在得到是不存在此符号。这只是我的猜想，并不一定正确。

我的JVM版本如下：

java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) 64-Bit Server VM (build 11.0-b15, mixed mode)

其中resin比较老，是3.0.21 pro版本。特别说明的是，这种情况是偶尔才出现，重启resin就消失了，所有字段可以正常访问。我一共遇到了两次，目前仍然不知道是JVM的bug还是resin的bug。

第二个诡异的事情是，听同事（两个以上人看过现象）描述他写了一个单例，如下：

public class Singleton {

    private static final Singleton instance = new Singleton();

    private Singleton() {
    }

    public static Singleton getInstance() {
        return instance;
    }
}

然后去调用getInstance()，结果居然得到一个null。特别说明的是没有ClassNotFoundException异常，没有java.lang.ExceptionInInitializerError异常，也没有java.lang.NoClassDefFoundError异常，没有任何异常，是一个真真正正的null。

当然了，比较诡异的是重启JVM就没有此现象了。此现象我没有重现过，也没有看到过，只是道途听说，不好过多评论。

以上两个问题有谁遇到过么？

难道是RP问题？灵异事件？JVM BUG？

imxylz 2010-08-12 00:54 发表评论

《深入浅出 Java Concurrency》暂停两天更新

imxylz — Fri, 16 Jul 2010 03:59:00 GMT

自从开了这个专题后发现时间明显不够用。前段时间几乎是每天一篇的速度更新，但是没写一篇都需要花3个小时以上的时间。这一方面是对知识的理解和经验不够，另一方面也确实是花了很多的时间做相关知识的准备和处理。

每写一篇文章需要考虑适用的场合，相关的设计思想和理论知识，代码中是如何实现，收集别人是何如理解和应用的，查阅相关的资料等等，感觉体力活比脑力活还要多。一句话，精力不够！

另外还有一个原因就是个人组织文料的能力不够，其实也是经验不足罢了，所以在操作上也是比较耗费精力的。

但是“时间挤挤还是有的”，所以从下周开始还是会继续更新的。这个周末好好考虑下，重新规划下接下来的章节该怎么进行。先休息两天吧。

imxylz 2010-07-16 11:59 发表评论

深入浅出 Java Concurrency (14): 锁机制 part 9 读写锁 (ReentrantReadWriteLock) (2)

imxylz — Wed, 14 Jul 2010 16:41:00 GMT

摘要:
这一节主要是谈谈读写锁的实现。
上一节中提到，ReadWriteLock看起来有两个锁：readLock/writeLock。如果真的是两个锁的话，它们之间又是如何相互影响的呢？
事实上在ReentrantReadWriteLock里锁的实现是靠java.util.concurrent.locks.ReentrantReadWriteLock.Sync完成的。这个类看起来比较眼熟，实际上它是AQS的一个子类，这中类似的结构在CountDownLatch、ReentrantLock、Semaphore里面都存在。同样它也有两种实现：公平锁和非公平锁，也就是java.util.concurrent.locks.ReentrantReadWriteLock.FairSync和java.util.concurrent.locks.ReentrantReadWriteLock.NonfairSync。这里暂且不提。
在ReentrantReadWriteLock里面的锁主体就是一个Sync，也就是上面提到的FairSync或者NonfairSync，所以说实际阅读全文

imxylz 2010-07-15 00:41 发表评论

深入浅出 Java Concurrency (13): 锁机制 part 8 读写锁 (ReentrantReadWriteLock) (1)

imxylz — Wed, 14 Jul 2010 06:18:00 GMT

摘要: 从这一节开始介绍锁里面的最后一个工具：读写锁(ReadWriteLock)。
ReentrantLock 实现了标准的互斥操作，也就是一次只能有一个线程持有锁，也即所谓独占锁的概念。前面的章节中一直在强调这个特点。显然这个特点在一定程度上面减低了吞吐量，实际上独占锁是一种保守的锁策略，在这种情况下任何“读/读”，“写/读”，“写/写”操作都不能同时发生。但是同样需要强调的一个概念是，锁是有一定的开销的，当并发比较大的时候，锁的开销就比较客观了。所以如果可能的话就尽量少用锁，非要用锁的话就尝试看能否改造为读写锁。
ReadWriteLock描述的是：一个资源能够被多个读线程访问，或者被一个写线程访问，但是不能同时存在读写线程。也就是说读写锁使用的场合是一个共享资源被大量读取操作，而只有少量的写操作（修改数据）。清单1描述了ReadWriteLock的API。阅读全文

imxylz 2010-07-14 14:18 发表评论

深入浅出 Java Concurrency (12): 锁机制 part 7 信号量（Semaphore）

imxylz — Tue, 13 Jul 2010 14:41:00 GMT

摘要: Semaphore 是一个计数信号量。从概念上讲，信号量维护了一个许可集。如有必要，在许可可用前会阻塞每一个 acquire()，然后再获取该许可。每个 release() 添加一个许可，从而可能释放一个正在阻塞的获取者。但是，不使用实际的许可对象，Semaphore 只对可用许可的号码进行计数，并采取相应的行动。
说白了，Semaphore是一个计数器，在计数器不为0的时候对线程就放行，一旦达到0，那么所有请求资源的新线程都会被阻塞，包括增加请求到许可的线程，也就是说Semaphore不是可重入的。每一次请求一个许可都会导致计数器减少1，同样每次释放一个许可都会导致计数器增加1，一旦达到了0，新的许可请求线程将被挂起。
缓存池整好使用此思想来实现的，比如链接池、对象池等。阅读全文

imxylz 2010-07-13 22:41 发表评论

深入浅出 Java Concurrency (11): 锁机制 part 6 CyclicBarrier

imxylz — Mon, 12 Jul 2010 15:33:00 GMT

摘要:
如果说CountDownLatch是一次性的，那么CyclicBarrier正好可以循环使用。它允许一组线程互相等待，直到到达某个公共屏障点 (common barrier point)。所谓屏障点就是一组任务执行完毕的时刻。
阅读全文

imxylz 2010-07-12 23:33 发表评论

深入浅出 Java Concurrency (10): 锁机制 part 5 闭锁 (CountDownLatch)

imxylz — Fri, 09 Jul 2010 01:21:00 GMT

摘要: 此小节介绍几个与锁有关的有用工具。
闭锁（Latch）
闭锁（Latch）：一种同步方法，可以延迟线程的进度直到线程到达某个终点状态。通俗的讲就是，一个闭锁相当于一扇大门，在大门打开之前所有线程都被阻断，一旦大门打开所有线程都将通过，但是一旦大门打开，所有线程都通过了，那么这个闭锁的状态就失效了，门的状态也就不能变了，只能是打开状态。也就是说闭锁的状态是一次性的，它确保在闭锁打开之前所有特定的活动都需要在闭锁打开之后才能完成。
CountDownLatch是JDK 5+里面闭锁的一个实现，允许一个或者多个线程等待某个事件的发生。CountDownLatch有一个正数计数器，countDown方法对计数器做减操作，await方法等待计数器达到0。所有await的线程都会阻塞直到计数器为0或者等待线程中断或者超时。阅读全文

imxylz 2010-07-09 09:21 发表评论

深入浅出 Java Concurrency (9): 锁机制 part 4

imxylz — Thu, 08 Jul 2010 04:33:00 GMT

摘要: 本小节介绍锁释放Lock.unlock()。
Release/TryRelease
unlock操作实际上就调用了AQS的release操作，释放持有的锁。阅读全文

imxylz 2010-07-08 12:33 发表评论

深入浅出 Java Concurrency (8): 锁机制 part 3

imxylz — Tue, 06 Jul 2010 16:05:00 GMT

摘要: 接上篇，这篇从Lock.lock/unlock开始。特别说明在没有特殊情况下所有程序、API、文档都是基于JDK 6.0的。
在没有深入了解内部机制及实现之前，先了解下为什么会存在公平锁和非公平锁。公平锁保证一个阻塞的线程最终能够获得锁，因为是有序的，所以总是可以按照请求的顺序获得锁。不公平锁意味着后请求锁的线程可能在其前面排列的休眠线程恢复前拿到锁，这样就有可能提高并发的性能。这是因为通常情况下挂起的线程重新开始与它真正开始运行，二者之间会产生严重的延时。因此非公平锁就可以利用这段时间完成操作。这是非公平锁在某些时候比公平锁性能要好的原因之一。阅读全文

imxylz 2010-07-07 00:05 发表评论

深入浅出 Java Concurrency (7): 锁机制 part 2 AQS

imxylz — Tue, 06 Jul 2010 10:29:00 GMT

摘要: 在理解J.U.C原理以及锁机制之前，我们来介绍J.U.C框架最核心也是最复杂的一个基础类：java.util.concurrent.locks.AbstractQueuedSynchronizer。

AQS
AbstractQueuedSynchronizer，简称AQS，是J.U.C最复杂的一个类，导致绝大多数讲解并发原理或者实战的时候都不会提到此类。但是虚心的作者愿意借助自己有限的能力和精力来探讨一二（参考资源中也有一些作者做了部分的分析。）。
首先从理论知识开始，在了解了相关原理后会针对源码进行一些分析，最后加上一些实战来描述。阅读全文

imxylz 2010-07-06 18:29 发表评论

深入浅出 Java Concurrency (6): 锁机制 part 1

imxylz — Mon, 05 Jul 2010 05:37:00 GMT

摘要: 前面的章节主要谈谈原子操作，至于与原子操作一些相关的问题或者说陷阱就放到最后的总结篇来整体说明。从这一章开始花少量的篇幅谈谈锁机制。
上一个章节中谈到了锁机制，并且针对于原子操作谈了一些相关的概念和设计思想。接下来的文章中，尽可能的深入研究锁机制，并且理解里面的原理和实际应用场合。
尽管synchronized在语法上已经足够简单了，在JDK 5之前只能借助此实现，但是由于是独占锁，性能却不高，因此JDK 5以后就开始借助于JNI来完成更高级的锁实现。
JDK 5中的锁是接口java.util.concurrent.locks.Lock。另外java.util.concurrent.locks.ReadWriteLock提供了一对可供读写并发的锁。根据前面的规则，我们从java.util.concurrent.locks.Lock的API开始。阅读全文

imxylz 2010-07-05 13:37 发表评论

深入浅出 Java Concurrency (5): 原子操作 part 4

imxylz — Sun, 04 Jul 2010 10:03:00 GMT

摘要: 在JDK 5之前Java语言是靠synchronized关键字保证同步的，这会导致有锁（后面的章节还会谈到锁）。
锁机制存在以下问题：
（1）在多线程竞争下，加锁、释放锁会导致比较多的上下文切换和调度延时，引起性能问题。
（2）一个线程持有锁会导致其它所有需要此锁的线程挂起。
（3）如果一个优先级高的线程等待一个优先级低的线程释放锁会导致优先级倒置，引起性能风险。
volatile是不错的机制，但是volatile不能保证原子性。因此对于同步最终还是要回到锁机制上来。
独占锁是一种悲观锁，synchronized就是一种独占锁，会导致其它所有需要锁的线程挂起，等待持有锁的线程释放锁。而另一个更加有效的锁就是乐观锁。所谓乐观锁就是，每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。阅读全文

imxylz 2010-07-04 18:03 发表评论

深入浅出 Java Concurrency (4): 原子操作 part 3 指令重排序与happens-before法则

imxylz — Sat, 03 Jul 2010 12:40:00 GMT

摘要: 在这个小结里面重点讨论原子操作的原理和设计思想。
由于在下一个章节中会谈到锁机制，因此此小节中会适当引入锁的概念。
在Java Concurrency in Practice中是这样定义线程安全的：
当多个线程访问一个类时，如果不用考虑这些线程在运行时环境下的调度和交替运行，并且不需要额外的同步及在调用方代码不必做其他的协调，这个类的行为仍然是正确的，那么这个类就是线程安全的。阅读全文

imxylz 2010-07-03 20:40 发表评论