杂记

首先说下高兴的事情，前两天拿到了第一张offer了，不用担心自己找不到工作了。但是这个工作是在深圳，本人是武汉人，还是挺不方便的，所以还在继续的找工作中

不高兴的事情，今天有场面试，要带上成绩单，于是去学工办去打印成绩单，靠，那女的 的态度真心让人不爽，应该是个研究生，郁闷。。。

 

OK，开始说技术把。

这些天一直在各种宣讲会，笔试面试，各种奔波，关键是我们这个校区太偏，所以基本一天都耗在公交上了，因此这几天学的东西有限：

1.自优化的代码：

这里所谓的优化，并不是对整个项目的优化，而是对自己写的代码进行优化，知道怎么写效率会高些，主要针对字符串

（1）就是String的split方法 对比StringTokenizer类，都是用指定的分隔符分解String，但是在效率上有差异

  首先给出测试代码：

    @Test
    public void test1() {
         String orgStr = null;
         StringBuffer sb = new StringBuffer();
         for(int i=0;i<100000;i++){
         sb.append(i);
         sb.append(",");
         }
         orgStr = sb.toString();
         long start = System.currentTimeMillis();
         String[] strs = orgStr.split(",");
         int count = 0;
         for(String s:strs) {
             count++;
         }
         System.out.println(count);
         long end = System.currentTimeMillis();
         System.out.println(end-start);
         
         start = System.currentTimeMillis();
         StringTokenizer st = new StringTokenizer(orgStr,",");
         count = 0;
         while(st.hasMoreTokens()) {
             String str = st.nextToken();
             count++;
         }
         System.out.println(count);
         end = System.currentTimeMillis();
         System.out.println(end-start);
    }

运行后的测试结果为

100000
38
100000
21

可以看到，当String很长，而且分解得到的String很多的时候，StringTokenizer的效率要高点。

但是 ： 用StringTokenizer 明显比直接用split方法要复杂一些

因此，在不是很要求效率的情况下，还是使用split方法，这个代码也看起来清晰一些，毕竟有时候代码的清晰比效率更重要一些

（2）字符串的连接

这个相信大家都知道，String是final的，连接字符串很多的话最好有StringBuilder（单线程）,或者StringBuffer(多线程)

然而我最近在一篇文章中看到了还可以用String的 concat方法来连接字符串，下面对比下这些连接方式的快慢

    @Test
    public void testStringConcat () {
         String str = null;
         String result = "";
         
         long start = System.currentTimeMillis();
         for(int i=0;i<10000;i++){
         str = str + i;
         }
         long end = System.currentTimeMillis();
         System.out.println(end-start);
         
         start = System.currentTimeMillis();
         for(int i=0;i<10000;i++){
         result = result.concat(String.valueOf(i));
         }
         end = System.currentTimeMillis();
         System.out.println(end-start);
         
         start = System.currentTimeMillis();
         StringBuilder sb = new StringBuilder();
         for(int i=0;i<10000;i++){
         sb.append(i);
         }
         end = System.currentTimeMillis();
         System.out.println(end-start);
    }

最后运行的结果为：

219
87
0

很明显，直接用+连接字符串耗时更长，但是按道理说这样写的代码编译器会帮我们进行优化，怎么还是耗这么长时间呢?按照那篇博客上看到的，是因为编译器不够智能，虽然会使用StringBuilder（StringBuffer）来连接，但是是每一次都建立一个新的StringBuilder(~)对象，我不知道是不是这样的

然后concat方法比直接用+效率要高，StringBuilder效率是最高的。

所以，我感觉，在想优化的地方，不要怕麻烦，使用StringBuilder或者StringBuffer，连接次数很少的地方还是使用+，感觉使用concat方法挺麻烦的.

(3)对局部变量的操作比全局变量的效率要高

测试代码：

    public static int b = 0;
    @Test
    public void testVariableCompare () {
         int a = 0;
         long starttime = System.currentTimeMillis();
         for(int i=0;i<1000000;i++){
         a++;//在函数体内定义局部变量
         }
         System.out.println(System.currentTimeMillis() - starttime);
         
         starttime = System.currentTimeMillis();
         for(int i=0;i<1000000;i++){
         b++;//在函数体内定义局部变量
         }
         System.out.println(System.currentTimeMillis() - starttime);
    }

运行结果：

2
3

从结果确实可以看出来这点，但是好像差别不是很大，但是还是可以注意一下这个点，在不破坏代码的可读性和清晰的时候，尽可能的使用局部变量把，我好像想到了effective java里面的一个建议，是类和成员的可访问性最小化，就是说如果一个变量只在for循环里面用到的话，就没必要在外面定义它等等。。。

（4）位运算优先

这个是肯定的，cpu是天然支持位运算的，中间不用任何的转化，测试代码

    @Test
    public void testOperator() {
         long start = System.currentTimeMillis();
         long a=1000;
         for(int i=0;i<10000000;i++){
         a*=2;
         a/=2;
         }
         System.out.println(a);
         System.out.println(System.currentTimeMillis() - start);
         start = System.currentTimeMillis();
         for(int i=0;i<10000000;i++){
         a<<=1;
         a>>=1;
         }
         System.out.println(a);
         System.out.println(System.currentTimeMillis() - start);
    }

结果如下：

1000
22
1000
5

很明显，位运算比*,/运算快了不止一点，所以之前在List源码里面看到扩展数组的时候就是用的位运算

 

OK，自由化就看了这么多，接下来的内容是java8的更新

2.java8

在之前的博文里面已经写过java8方面的内容了，现在写的是之前没有写到的，主要是java.util.stream包里面的的内容

之前确实看到util里面多了个stream，但是不知道是干什么的，现在看了一篇博客后，会简单的使用了

使用如下：

    @Test
    public void test() {
        List<String> list = new ArrayList<>();
        list.addAll(Arrays.asList("first","second","third"));
        long count = list.stream().filter(data -> !data.equals("first")).count();
        System.out.println(count);
        
        List<String> list1 = list.stream().map(data -> data + data).collect(Collectors.toList());
        list1.forEach(System.out::println);
        
        List<String> list2 = list.stream().map(data -> data.toUpperCase()).collect(Collectors.toList());
        list2.forEach(System.out::println);
        
    }

得到的结果：

2
firstfirst
secondsecond
thirdthird
FIRST
SECOND

来分析下这段代码，现在每个List,Set,Map.好像都有一个stream方法，这个方法会建立一个流（注意，这个流跟inputstream没关系，也不一样）,然后就能够使用里面的一些方法了，比如上面使用到的filter 可以过滤掉容器里面的部分内容，count，得到最后的数量，当然还有很多方法，大家可以去看看和尝试下，感觉stream和lambda表达式一起使用挺方便的，

可以通过stream来新建一个List,

最后，增强的forEach方法，是遍历的一个方法，可以和lambda表达式一起使用，可以代替for  in 循环

关于stream，我就讲到这里了，里面还有很多东西，以后再去看。

3.关于guava，

之前一直想学习使用guava的，但是发现里面的部分内容，在jdk里面直接实现了，就放弃了学习。

最近发现里面的collection这个里面的东西还挺有趣的，所以又看了下，主要是collection

（1）首先是不可变集合，jdk里面可以通过Collection.unmodifiable*方法来得到一个不可变集合，但是这个不可变集合并非是真的不可变的，对得到的集合进行操作的话，确实会抛出异常，但是如果对原集合进行操作的话，也会将得到的不可变集合的内容给改动

测试代码如下：

    @Test
    public void testOld() {
         Set<String> set = new HashSet<String>(Arrays.asList(new String[]{"RED", "GREEN"})); 
         Set<String> unmodifiableSet = Collections.unmodifiableSet(set);
         set.forEach(data -> {
             System.out.println(data);
         });
         unmodifiableSet.forEach(data -> {
             System.out.println(data);
         });
         
         set.remove("RED");
         System.out.println("---after remove---");
         
         set.forEach(data -> {
             System.out.println(data);
         });
         unmodifiableSet.forEach(data -> {
             System.out.println(data);
         });
    }

测试结果如下：

RED
GREEN
RED
GREEN
---after remove---
GREEN
GREEN

可以看到，我只将set里面的RED删除了，但是unmodifiableSet里面的内容也删除了。

看看guava里面的immutableSet:

    @Test
    public void testGuavaImmutableSet() {
        Set<String> set = new HashSet<String>(Arrays.asList(new String[]{"RED", "GREEN"})); 
        ImmutableSet<String> immutableSet = ImmutableSet.copyOf(set);
        
        set.forEach(data -> {
             System.out.println(data);
         });
        immutableSet.forEach(data -> {
            System.out.println(data);
        });
        
        set.remove("RED");
        System.out.println("---after remove---");
        
        set.forEach(data -> {
             System.out.println(data);
         });
        immutableSet.forEach(data -> {
            System.out.println(data);
        });
    }

测试结果如下：

RED
GREEN
RED
GREEN
---after remove---
GREEN
RED
GREEN

就没有这个问题，从方法名上也大概可以看到，jdk里面的方法，估计是将原来的set包在unmodifiableSet里面去了，但是guava是复制了一份内容保存，当然这只是猜测，没有去看源码，因为eclipse居然看不到源码，还是idea好

 

然后里面还有multiSet 可以插入重复值，MultiMap 一个key可以对应多个value，biMap 一个key，对应一个value，并且一个value，对应一个key，也就是一一对应。这些集合的代码就不复制出来了，不然又是全篇都是代码了。

OK，今天就写到这里把，之后几天争取再拿几张offer，争取将华为的offer拿到，加油