杂记
首先说下高兴的事情，前两天拿到了第一张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拿到，加油
