配图：3D立体街头涂鸦

     博客连着断了一个月没更新，期间写过好几篇各个方向的文，都是写到一半就夭折，这篇文章强迫自己耐心写出来的。最近跟出版社沟通好了在写一本关于代码审计和安全编程的书，算是把我这几年的技术积累做一个总结，刚好昨天跟safekey team几个搞渗透的朋友说到编程的问题，就想写个文来好好讲讲。

博主猜你喜欢：
PHP代码审计学习总结 某牛的经验之作	帮助新手学习代码审计，分享WEB安全代码审计文章整理打包	PHP代码审计基础知识 对新手来说很精品哦	PHP编程函数安全篇	介绍公司php漏洞挖掘与代码审计方法
无觅

　　前端开发是有逻辑的，这点毋庸置疑。程序员的思维逻辑赋予了代码各种能力，但是前端开发中经常面对的是用户的操作。在一个比较复杂的页面中（貌似现在也很少有简单页面了），用户的操作是不可预见的，假如有很多按钮，每个按钮都会做一件自己独一无二的事，如果上帝保佑所有的这些操作，这些事件都彼此没有限制，而且结果互不影响，那没有问题。但在开发中好像没有这种好运气，所以经常需要协调和平衡这些函数之间的执行。

　　如果你使用的是纯JS或者单独仅有jQuery的情况下，遇到这种让人焦头烂额的情形会尤为明显，前端MVC一定程度上隐藏了并处理了这些问题，但是也并不完全。这个时候你可能需要了解一下关于”有限状态机“的概念，前端开发中这应该是一个很有用的东西。

　　描述一下”有限状态机“：

有限状态自动机，简称状态机，是表示有限个状态以及在这些状态之间的转移和动作等行为的数学模型。

状态总数（state）是有限的。

任一时刻，只会处于一种状态中。

在某种条件下，会从一种状态转变到另一种状态中。

在维基百科中称:有限状态机FSM是设计和实现事件驱动程序内复杂行为组织原则的有力工具。

　　对于前端来说，尤其是Javascript编程时，这个模型的意义就在于可以将其套用在很多对象上。具体个例子，比如一个按钮平时就是正常的按钮，当你点击后变成一个input。当然你可能会说这么简单的功能，我直接用jQuery甚至不用都可以，操作DOM显示和隐藏就好了。如果你还抱有这种天真的想法，我只能说你没遇到过让你痛不欲生的页面。。。当页面复杂到一定程度，单纯操作DOM去处理前端只会加快你疯掉的进程。

　　这里对于Button套用有限状态机的模型，相当btn对象只有两个状态，显示状态和编辑状态。看看代码吧：

　　上面就是有限状态机的写法，逻辑和层次上确实清晰了，对于状态越多的对象，就越适合这种写法。

　　通过有限状态机的这种模式,我认为最重要的一点就是将用户的操作行为,也就是组件的事件响应(比如点击)与组件的行为表现分离开来.在确切的说,通过建立一个有限状态机的模型,我们完全不关心用户的点击行为具体做了什么,这时组件可能会有几种状态对应不同的表现形式,而用户触发的事件仅仅是切换了模型的状态.至于每个状态的具体表现和行为,我们完全可以单独定义,也就说这时一种行为和响应上的解耦.

　　Github上有两个比较好的库,都是实现FSM的,有兴趣可以具体看看:

　　 https://github.com/fschaefer/Stately.js

　　 https://github.com/jakesgordon/javascript-state-machine

介绍Android中Http请求方式的选择、区别及几个常用框架对API的选择

1. 两种请求方式对比
Android Http请求API主要分两种：
第一种是Java的HttpURLConnection，默认带gzip压缩
第二种Apache的HttpClient，默认不带gzip压缩
两种方式请求connection都是keep alive，默认User-Agent不同。

关于两种方式发出去的请求头对比图如下：

上图是通过抓包抓包的，具体如何抓包可参考： Android利用Fiddler进行网络数据抓包
测试代码见： android-http-api-compare@github, 测试APK见： http-api-compare.apk

2. 常用Http框架对Http API的选择
Retrofit及Volley框架默认在Android API 9及以上都是用HttpURLConnection，9以下用HttpClient。

这样我们也能看出就算我们自己不使用框架对这两个API的选择了.

3. GZip压缩
一般对于API请求需带上GZip压缩，因为API返回数据大都是JSon串之类字符串，GZip压缩后内容大小大幅降低，下面是这两个网页GZip压缩前后对比，都是第一条表示GZip压缩后，第二条为压缩前

更多关于网络请求优化请参考： Android性能优化第四部分网络的介绍

1. 高端人才短缺。对于整个加工制作的流水线来讲，我们现在还集中在中下游的阶段，创作型人才短缺。无论是故事、角色形象都缺乏亮点。头几年有个《魔比斯环》还记得吧？上百个年轻人，花了几个亿，熬了两三年，做出来个四不像的东西，因为导演、编剧都是外国人，一个国产动画片能把对白写的跟译制片一样（哦，好了莱纳德，你再这样我就要踢你的屁股了，哦我发誓我会这样的。就是这种感觉你体会一下），真是让人哭笑不得。高等教育在影视方面基本上还都是应用型，比如我的母校中国传媒大学，大部分都是技术教学，对于创作能力的培养不是说没有，但是受制于体质、就业、生源质量和国家支持等因素，并不是很成功。
   
2. 市场极度饥渴，但大多满足于赚快钱。可以看看国内近些年火爆的影片，要么都是粗制滥造（但成本可不低）但是商业运作成功票房令人咂舌的大动画电影，要么就是夫妻俩憋了几个月放在视频网站上引起轰动的小作坊出品。大家发现粗制滥造就能有高票房，影视投资人是什么人相信大家也都知道（煤老板都可以做），投资影视对他们来讲「玩」（动画角色没什么可玩的，真人电影嘛...呵呵）和「赚钱」一半一半，什么行业的良性发展呀，人才的培养和积累啊，洗洗睡吧人家不在乎。没有人想过，烂片也能挣大钱正说明了市场的饥渴和需求（都已经不是潜在需求了）的旺盛，没有人愿意为这个行业明天的发展抛头颅洒热血，愿意想愿意做这些的又都是从事基层工作的热血青年（比如夫妻小作坊），没有话语权没有影响力。
3. 行业监管、政策跟不上。到现在连个分级制度都没有，审片制度不仅不透明结果更经常让人无语，可想而知整个行政监管多么落后了。光腚粽菊不是摆设，再加上文化部、教育部各种部委的多线干涉，影视行业是人家的玩物，做什么都是为了政绩服务，而不是以民为本的支持。在中国拍电影，最大的敌人和阻碍就是这些本应该最支持你的人。

• —软件人才免语言低担保 赴美带薪读研！—

• —软件人才免语言低担保 赴美带薪读研！—

1. 不小心重用了流

我敢打赌，每人至少都会犯一次这样的错误。就像现有的这些“流”（比如说InputStream）,你也只能对它们消费一次。下面的代码是无法工作的：

IntStream stream = IntStream.of(1, 2);
stream.forEach(System.out::println);

// That was fun! Let's do it again!
stream.forEach(System.out::println);

你会碰到一个这样的错误：

java.lang.IllegalStateException: 
  stream has already been operated upon or closed

因此使用流的时候应当格外注意。它只能消费一次。

1. 不小心创建了一个”无限"流

你可能一不留神就创建了一个无限流。就拿下面这个例子来说：

IntStream.iterate(0, i -> i + 1)
         .forEach(System.out::println);

流的问题就在于它有可能是无限的，如果你的确是这样设计的话。唯一的问题就是，这并不是你真正想要的。因此，你得确保每次都给流提供一个适当的大小限制：

// That's better
IntStream.iterate(0, i -> i + 1)
         .limit(10)
         .forEach(System.out::println);

1. 不小心创建了一个“隐藏的”无限流

这个话题是说不完的。你可能一不小心就真的创建了一个无限流。比如说下面的这个：

IntStream.iterate(0, i -> ( i + 1 ) % 2)
         .distinct()
         .limit(10)
         .forEach(System.out::println);

这样做的结果是：

• 我们生成了0和1的交替数列
• 然后只保留不同的数值，比如说，一个0和一个1
• 然后再将流的大小限制为10
• 最后对流进行消费

好吧，这个distinct()操作它并不知道iterate()所调用的这个函数生成的只有两个不同的值。它觉得可能还会有别的值。因此它会不停地从流中消费新的值，而这个limit(10)永远也不会被调用到。不幸的是，你的应用程序会崩掉。

1. 不小心创建了一个”隐藏”的并行无限流

我还是想继续提醒下你，你可能真的一不小心就消费了一个无限流。假设你认为distinct()操作是会并行执行的。那你可能会这么写：

IntStream.iterate(0, i -> ( i + 1 ) % 2)
         .parallel()
         .distinct()
         .limit(10)
         .forEach(System.out::println);

现在我们可以知道的是，这段代码会一直执行下去。不过在前面那个例子中，你至少只消耗了机器上的一个CPU。而现在你可能会消耗四个，一个无限流的消费很可能就会消耗掉你整个系统的资源。这可相当不妙。这种情况下你可能得去重启服务器了。看下我的笔记本在最终崩溃前是什么样的:

1. 操作的顺序

为什么我一直在强调你可能一不小心就创建了一个无限流？很简单。因为如果你把上面的这个流的limit()和distinct()操作的顺序掉换一下，一切就都OK了。

IntStream.iterate(0, i -> ( i + 1 ) % 2)
         .limit(10)
         .distinct()
         .forEach(System.out::println);

现在则会输出：

0
1

为什么会这样？因为我们先将无限流的大小限制为10个值，也就是(0 1 0 1 0 1 0 1 0 1)，然后再在这个有限流上进行归约，求出它所包含的不同值，（0，1）。

当然了，这个在语义上就是错误的了。因为你实际上想要的是数据集的前10个不同值。没有人会真的要先取10个随机数，然后再求出它们的不同值的。

如果你是来自SQL背景的话，你可能不会想到还有这个区别。就拿SQL Server 2012举例来说，下面的两个SQL语句是一样的：

-- Using TOP
SELECT DISTINCT TOP 10 *
FROM i
ORDER BY ..

-- Using FETCH
SELECT *
FROM i
ORDER BY ..
OFFSET 0 ROWS
FETCH NEXT 10 ROWS ONLY

因此，作为一名SQL用户，你可能并不会注意到流操作顺序的重要性。

1. 还是操作顺序

既然说到了SQL，如果你用的是MySQL或者PostgreSQL，你可能会经常用到LIMIT .. OFFSET子句。SQL里全是这种暗坑，这就是其中之一。正如SQL Server 2012中的语法所说明的那样，OFFSET子名会优先执行。

如果你将MySQL/PostgreSQL方言转化成流的话，得到的结果很可能是错的：

IntStream.iterate(0, i -> i + 1)
         .limit(10) // LIMIT
         .skip(5)   // OFFSET
         .forEach(System.out::println);

上面的代码会输出：

5
6
7
8
9

是的，它输出9后就结束了，因为首先生效的是limit()，这样会输出(0 1 2 3 4 5 6 7 8 9)。其次才是skip()，它将流缩减为(5 6 7 8 9)。而这并不是你所想要的。

警惕LIMIT .. OFFSET和OFFSET .. LIMIT的陷阱！

1. 使用过滤器来遍历文件系统

这个问题我们之前已经讲过了。使用过滤器来遍历文件系统是个不错的方式：

Files.walk(Paths.get("."))
     .filter(p -> !p.toFile().getName().startsWith("."))
     .forEach(System.out::println);

看起来上面的这个流只是遍历了所有的非隐藏目录，也就是不以点号开始的那些目录。不幸的是，你又犯了错误五和错误六了。walk()方法已经生成一个当前目录下的所有子目录的流。虽然是一个惰性流，但是也包含了所有的子路径。现在的这个过滤器可以正确过滤掉所有名字以点号开始的那些目录，也就是说结果流中不会包含.git或者.idea。不过路径可能会是:..git\refs或者..idea\libraries。而这并不是你实际想要的。

你可别为了解决问题而这么写：

Files.walk(Paths.get("."))
     .filter(p -> !p.toString().contains(File.separator + "."))
     .forEach(System.out::println);

虽然这么写的结果是对的，但是它会去遍历整个子目录结构树，这会递归所有的隐藏目录的子目录。

我猜你又得求助于老的JDK1.0中所提供的File.list()了。不过好消息是， FilenameFilter和FileFilter现在都是函数式接口了。

1. 修改流内部的集合

当遍历列表的时候，你不能在迭代的过程中同时去修改这个列表。这个在Java 8之前就是这样的，不过在Java 8的流中则更为棘手。看下下面这个0到9的列表：

// Of course, we create this list using streams:
List<Integer> list = 
IntStream.range(0, 10)
         .boxed()
         .collect(toCollection(ArrayList::new));

现在，假设下我们在消费流的时候同时去删除元素：

list.stream()
    // remove(Object), not remove(int)!
    .peek(list::remove)
    .forEach(System.out::println);

有趣的是，其中的一些元素中可以的删除的。你得到的输出将会是这样的：

0
2
4
6
8
null
null
null
null
null
java.util.ConcurrentModificationException

如果我们捕获异常后再查看下这个列表，会发现一个很有趣的事情。得到的结果是：

[1, 3, 5, 7, 9]

所有的奇数都这样。这是一个BUG吗？不，这更像是一个特性。如果你看一下JDK的源码，会发现在ArrayList.ArraListSpliterator里面有这么一段注释：

/* * If ArrayLists were immutable, or structurally immutable (no * adds, removes, etc), we could implement their spliterators * with Arrays.spliterator. Instead we detect as much * interference during traversal as practical without * sacrificing much performance. We rely primarily on * modCounts. These are not guaranteed to detect concurrency * violations, and are sometimes overly conservative about * within-thread interference, but detect enough problems to * be worthwhile in practice. To carry this out, we (1) lazily * initialize fence and expectedModCount until the latest * point that we need to commit to the state we are checking * against; thus improving precision. (This doesn't apply to * SubLists, that create spliterators with current non-lazy * values). (2) We perform only a single * ConcurrentModificationException check at the end of forEach * (the most performance-sensitive method). When using forEach * (as opposed to iterators), we can normally only detect * interference after actions, not before. Further * CME-triggering checks apply to all other possible * violations of assumptions for example null or too-small * elementData array given its size(), that could only have * occurred due to interference. This allows the inner loop * of forEach to run without any further checks, and * simplifies lambda-resolution. While this does entail a * number of checks, note that in the common case of * list.stream().forEach(a), no checks or other computation * occur anywhere other than inside forEach itself. The other * less-often-used methods cannot take advantage of most of * these streamlinings. */

现在来看下如果我们对这个流排序后会是什么结果：

list.stream()
    .sorted()
    .peek(list::remove)
    .forEach(System.out::println);

输出的结果看起来是我们想要的：

0
1
2
3
4
5
6
7
8
9

而流消费完后的列表是空的：

[]

也就是说所有的元素都正确地消费掉并删除了。sorted()操作是一个“带状态的中间操作”，这意味着后续的操作不会再操作内部的那个集合了，而是在一个内部的状态上进行操作。现在你可以安全地从列表里删除元素了！

不过，真的是吗这样？我们来试一下带有parallel(), sorted()的删除操作：

list.stream()
    .sorted()
    .parallel()
    .peek(list::remove)
    .forEach(System.out::println);

这个会输出 ：

7
6
2
5
8
4
1
0
9
3

现在列表里包含：

[8]

唉呀。居然没有删完所有的元素？！谁能解决这个问题，我免费请他喝酒！

这些行为看起来都是不确定的，我只能建议你在使用流的时候不要去修改它内部的数据集合。这样做是没用的。

1. 忘了去消费流

你觉得下面这个流在做什么？

IntStream.range(1, 5)
         .peek(System.out::println)
         .peek(i -> { 
              if (i == 5) 
                  throw new RuntimeException("bang");
          });

看完这段代码，你觉得应该会输出(1 2 3 4 5)然后抛出一个异常。不过并不是这样。它什么也不会做。这个流并没有被消费掉，它只是静静的待在那里。

正如别的流API或者DSL那样，你可能会忘了调用这个终止操作。当你使用peek()的时候也是这样的，因为peek有点类似于forEach()。

在jOOQ中也存在这样的情况，如果你忘了去调用 execute()或者fetch():

DSL.using(configuration)
   .update(TABLE)
   .set(TABLE.COL1, 1)
   .set(TABLE.COL2, "abc")

   .where(TABLE.ID.eq(3));

杯具。忘了调用execute方法了。

1. 并行流死锁

终于快讲完了～

如果你没有正确地进行同步的话，所有的并发系统都可能碰到死锁。现实中的例子可能不那么明显，不过如果你想自己创造一个场景的话倒是很容易。下面这个parallel()流肯定会造成死锁：

Object[] locks = { new Object(), new Object() };

IntStream
    .range(1, 5)
    .parallel()
    .peek(Unchecked.intConsumer(i -> {
        synchronized (locks[i % locks.length]) {
            Thread.sleep(100);

            synchronized (locks[(i + 1) % locks.length]) {
                Thread.sleep(50);
            }
        }
    }))
    .forEach(System.out::println);

注意这里Unchecked.intConsumer()的使用，它把IntConsumer接口转化成了 org.jooq.lambda.fi.util.function.CheckedIntConsumer，这样你才可以抛出已检查异常。

好吧。这下你的机器倒霉了。这些线程会一直阻塞下去:-)

不过好消息就是，在Java里面要写出一个这种教科书上的死锁可不是那么容易。

想进一步了解的话，可以看下Brian Goetz在StackOverflow上的 一个回答。

结论

引入了流和函数式编程之后，我们开始会碰到许多新的难以发现的BUG。这些BUG很难避免，除非你见过并且还时刻保持警惕。你必须去考虑操作的顺序，还得注意流是不是无限的。

流是一个非常强大的工具，但也是一个首先得去熟练掌握的工具。

原创文章转载请注明出处： Java 8中10个不易察觉的错误英文原文链接

• —软件人才免语言低担保 赴美带薪读研！—

var oldFile1 = document.getElementById("f1");
var newFile1 = oldFile1.cloneNode(true);
oldFile1.parentNode.replaceChild(newFile1, oldFile1);

• —软件人才免语言低担保 赴美带薪读研！—

• —软件人才免语言低担保 赴美带薪读研！—

　　《你真的离不开新闻吗》，这是一篇来自罗尔夫•多贝里的文章，也是来自《明智行动的艺术》一书最后的部分。在这篇文章看完之后，我决定断掉一些经常刷新的东西，比如朋友圈，来尝试一下不看新闻是否能带来价值。如果刷朋友圈是寻找存在感，那么我们的一生有很多可以追求的东西，以下为全文，我直接帖了出来。这种转载其实是并不负责的，但如果你喜欢这个文章，我还是功你去购买《 明智行动的艺术》原书。

　　苏门答腊的地震、俄罗斯的坠机事件、一个男人将自己的女人在地下室关了30年、海蒂·克鲁姆和席尔分手、德意志银行破纪录的工资报酬、在巴基斯坦发生的暗杀、马里总统的辞职、掷铅球的最新世界纪录，人们真的必须要知道这些事情？

　　我们的信息很灵通，但知道的很少，为什么呢？因为我们在200年前发明了一种有毒的知识类型：新闻，即世界各地的消息报道。新闻对于我们的精神的影响，就像糖对于身体的影响一样：新闻是可口的，容易消化的—但长期下来却是有害的。

　　3年前我开始进行一个实验。我决定不再阅读新闻，取消了所有报纸和杂志的订阅，把电视机和收音机从家中搬走，将苹果手机上的新闻应用程序删除，我不再碰任何一份免费的报纸，而且当飞机上有人在我面前阅读报纸时，我会有意识地看向别处。在最开始的几个星期这么做是不容易的，很煎熬，我总害怕会错过些什么。但在一段时间之后，我有了一种新的生活感觉。3年之后，我的思维变得更清晰，见识更深远，可以做出更好的决定，有了更多的时间，而且最好的一点是：我从未错过什么重要的新闻。我的社交圈子—不是指脸谱网，而是现实中真正的朋友和熟人—起着新闻过滤器的作用。

　　回避新闻有很多的理由，我这里只说最重要的三个。第一： 我们的大脑对于骇人听闻的、与人物相关的、喧闹的和变换快的刺激会有极为强烈的反应—而对于抽象的、复杂的、需要解释的信息则有着极为微弱的反应。新闻制作者便利用了这一点。吸引人的故事、显眼的图片和耸人听闻的“事实”会牢牢吸引着我们的注意力，结果就是所有构思缜密的、复杂的、抽象的和不易看透的内容都会自动地被隐去，尽管这些内容与我们的生活和与对世界的理解更加相关。所以说为新闻消费的结果就是凭借一张错误的危机入场券在大脑中闲逛。花钱去看新闻的人会把大多数话题的重要性完全估计错误，他们在报纸上读到的那些危机不是真正的危机。

　　第二： 新闻的意义是不大的。人们可以在过去的1年内看完大约一万则短新闻—每天约30则。请你很诚实地说出一则新闻，它使你能比以前做出更好的决定—对你的生活、事业或生意。没有人在我提了这个问题之后能说出2则以上的新闻—从一万则新闻中。多么可悲的比率。新闻机构要的是使你相信，他们给你提供了更具竞争力的优势，很多人就这样受骗了。实际上关注新闻不是什么竞争力的优势，而是种劣势。如果关注新闻真的可以使人们获得更多成功，那么记者早就应该站在收入金字塔的顶端了，但他们并不是这样。

　　第三： 浪费时间。普通人因为新闻平均每周浪费半个工作日。从全球范围看来，这给生产力带来的损失是很大的。比如2008年在孟买发生的恐怖袭击，恐怖分子在残酷的自我满足欲望中杀害了200人。请你想象一下：平均一个小时有10亿人在关注孟买的悲剧，他们关注着这一新闻，听着电视上某些“专家”和“评论家”的喋喋不休。这是个很符合实际的推算，因为在印度有超过10亿的人口，但我们还是按照10亿保守地计算，10亿人每关注一个小时加起来就是10亿个小时，换算过来就是：有2000个人的寿命被新闻消耗了—比恐怖袭击造成的死亡人数还多9倍，这个视角虽然很讽刺但也很现实。

　　消除掉这100多个思维错误和行动错误，与放弃新闻一样，可以给你带来的益处是显而易见的。你害怕没有新闻的生活会使你被朋友们排斥？你也许不知道在西伯利亚某处有飞机坠毁，但是你可以理解这世上深层次的而且往往不是一目了然的关联，你可以将这些与其他人分享。谈到你不看新闻的事情时你不要有顾虑，人们会很感兴趣地听你讲述。长话短说，请你放弃对新闻的消费，而且是全部。你可以阅读长篇的背景文章和书籍，因为如果想要理解这个世界的话，没有比读书更好的方法了。

即使放到现在来看，我们依然可以说，移动搜索还不算是太成功的那一类产品。

一方面，用户的搜索习惯正在从PC向移动设备延伸，高达90.4%的用户会在手机上使用搜索功能；另一方面，用户并不喜欢移动搜索产品，高达61.4%的用户觉得在手机上搜索比在PC上困难得多。（数据出自： Serch Engine Land）

于是，你可以看到这样一个怪象—— 搭了“传统互联网没落”便车的移动搜索产品在获得大量用户的同时，却仍然没有找到一个真正被移动互联网用户所接纳的产品形态。用户并不怎么喜欢移动搜索产品，他们之所以还在用是因为不得不用。而以Siri为代表的语音搜索也没能真正改善移动搜索体验，只有区区18.5%的用户认为语音搜索提高了移动搜索体验。

除了通过引入新的交互模式来改善移动搜索的产品形态，搜索服务商们将搜索结果内容结构化，而非提供一堆链接。另一方面，随着互联网内容逐渐向移动应用内转移，应用内内容的搜索也开始变得越来越重要。

Google在2013年12月开始支持 应用内的内容索引（App Indexing），他们希望借此将应用内容与各个网站进行连接，使得Google搜索结果能够提供应用的Deep Link（深层链接）。在搜索结果内展示应用内的内容，需要开发者做两件事：更新应用，增加对Deep Link的支持；将应用的Deep Link提供给Google。

在中国，豌豆荚则是另一家较早涉足应用内搜索的公司，他们从2013年8月开始做应用内搜索的第一个产品——视频搜索。今年3月，豌豆荚上线了“ 应用内搜索技术协议”，在推出自己标准的同时兼容Google的App Indexing标准和Quixey的AppURL标准。他们希望合作伙伴将自己的应用内容接入到豌豆荚里，让用户能够搜索到应用内容。

Deep Link是支持应用内搜索的一个必要环节。“我们应用内搜索这个事需要有几个环节，第一件事是我们需要知道内容在哪里，因为内容都是在一个一个应用信息孤岛里面，我们需要想办法把内容从信息孤岛里面拉出来。第二步我们需要知道怎么消费这个内容，怎么消费内容就跟Deep Link有关。”豌豆荚搜索技术负责人李大海对PingWest说，“比较通俗地说， Deep Link就是描述我们怎么展现，怎么打开，怎么处理应用里面的内容。”

但Deep Link仍然不够普及。根据李大海向PingWest透露的数据， 在最热门的1000款应用里，真正友好支持“调起”的应用不会超过20家。这意味着，绝大多数开发者需要对自己的应用进行修改来支持对Deep Link的支持。

“早期的时候，所有开发者更关注自己的业务，‘调起’只要能工作就好了，不太关注这个事情是不是满足规范，因为这完全是内部行为。现在的现实是， 很多开发者虽然自己的产品体验比较好，但是‘调起’这块情况非常糟糕，甚至完全不支持对外部的”调起”，有一些还会刻意的说我就不允许外部‘调起’。这会给外部‘调起’带来很大的困难，甚至产生很多无形当中的障碍。”李大海对PingWest说。

这些对“调起”并不那么在意的开发者，在制造了一大批不合乎标准的应用的同时，也给应用内搜索的实现制造了障碍。

于是，你会发现 在App Store里的应用越来越多的同时，移动搜索不管是在体验还是对应用内搜索的支持度上都没有相应地跟上。最明显的例子是，Google的App Indexing上线半年以来接入的第三方应用不足百家，豌豆荚上线应用内搜索SDK三个月以来接入的应用为30家——要知道他们收录的应用数量已经超过了150万个。

（Facebook的App Link介绍）

不仅如此， 各家的应用内搜索技术标准还处于各自为战的混乱状态。除了Google的App Indexing、Quixey的AppURL外，Facebook最近也上线了自己的标准App Links。虽然方案很多，但是应用内搜索还没有形成统一的标准，也缺少一个像W3C这样的中间机构来出面统一标准。

“传统互联网发明了hyperlink（超链接）以后才开始变得宽广起来， 但是移动互联网最早基于的是应用，信息的流动不是一开始考虑的重点。随着内容也转移到手机上，内容的流动和容易被发现变得越来越重要，信息孤岛限制了信息的自然流动。“李大海对PingWest说，“每个厂商都希望从自己的角度出发解决问题。例如，Google把网页和应用结合在一起，是因为他们更熟悉网页内容。“

为什么移动搜索产品都那么糟糕？你可以拿“标准的不统一”“开发者的不在意”和“交互模式的落后”来解释。从互联网的发明到基于超链接的万维网的出现经历了约二十年时间，但愿在移动互联网时代，我们不必经历那么长久的等待。

题图出处： shutterstock

相关阅读：

     对话豌豆荚搜索技术负责人李大海：“应用内搜索”到底有多难？

     追踪你的健康数据这件事，Google的方案也要来了

     Facebook的“去Facebook化”

     【PW晨报】易到用车出海，将入驻旧金山和纽约市

转自：http://www.iteye.com/topic/103804

首先，ThreadLocal 不是用来解决共享对象的多线程访问问题的，一般情况下，通过ThreadLocal.set() 到线程中的对象是该线程自己使用的对象，其他线程是不需要访问的，也访问不到的。各个线程中访问的是不同的对象。 

另外，说ThreadLocal使得各线程能够保持各自独立的一个对象，并不是通过ThreadLocal.set()来实现的，而是通过每个线程中的new 对象 的操作来创建的对象，每个线程创建一个，不是什么对象的拷贝或副本。通过ThreadLocal.set()将这个新创建的对象的引用保存到各线程的自己的一个map中，每个线程都有这样一个map，执行ThreadLocal.get()时，各线程从自己的map中取出放进去的对象，因此取出来的是各自自己线程中的对象，ThreadLocal实例是作为map的key来使用的。 

如果ThreadLocal.set()进去的东西本来就是多个线程共享的同一个对象，那么多个线程的ThreadLocal.get()取得的还是这个共享对象本身，还是有并发访问问题。 

下面来看一个hibernate中典型的ThreadLocal的应用： 

Java代码  

1. private static final ThreadLocal threadSession = new ThreadLocal();  
2.   
3. public static Session getSession() throws InfrastructureException {  
4.     Session s = (Session) threadSession.get();  
5.     try {  
6.         if (s == null) {  
7.             s = getSessionFactory().openSession();  
8.             threadSession.set(s);  
9.         }  
10.     } catch (HibernateException ex) {  
11.         throw new InfrastructureException(ex);  
12.     }  
13.     return s;  
14. }  

可以看到在getSession()方法中，首先判断当前线程中有没有放进去session，如果还没有，那么通过sessionFactory().openSession()来创建一个session，再将session set到线程中，实际是放到当前线程的ThreadLocalMap这个map中，这时，对于这个session的唯一引用就是当前线程中的那个ThreadLocalMap（下面会讲到），而threadSession作为这个值的key，要取得这个session可以通过threadSession.get()来得到，里面执行的操作实际是先取得当前线程中的ThreadLocalMap，然后将threadSession作为key将对应的值取出。这个session相当于线程的私有变量，而不是public的。 
显然，其他线程中是取不到这个session的，他们也只能取到自己的ThreadLocalMap中的东西。要是session是多个线程共享使用的，那还不乱套了。 
试想如果不用ThreadLocal怎么来实现呢？可能就要在action中创建session，然后把session一个个传到service和dao中，这可够麻烦的。或者可以自己定义一个静态的map，将当前thread作为key，创建的session作为值，put到map中，应该也行，这也是一般人的想法，但事实上，ThreadLocal的实现刚好相反，它是在每个线程中有一个map，而将ThreadLocal实例作为key，这样每个map中的项数很少，而且当线程销毁时相应的东西也一起销毁了，不知道除了这些还有什么其他的好处。 

总之，ThreadLocal不是用来解决对象共享访问问题的，而主要是提供了保持对象的方法和避免参数传递的方便的对象访问方式。归纳了两点： 
1。每个线程中都有一个自己的ThreadLocalMap类对象，可以将线程自己的对象保持到其中，各管各的，线程可以正确的访问到自己的对象。 
2。将一个共用的ThreadLocal静态实例作为key，将不同对象的引用保存到不同线程的ThreadLocalMap中，然后在线程执行的各处通过这个静态ThreadLocal实例的get()方法取得自己线程保存的那个对象，避免了将这个对象作为参数传递的麻烦。 

当然如果要把本来线程共享的对象通过ThreadLocal.set()放到线程中也可以，可以实现避免参数传递的访问方式，但是要注意get()到的是那同一个共享对象，并发访问问题要靠其他手段来解决。但一般来说线程共享的对象通过设置为某类的静态变量就可以实现方便的访问了，似乎没必要放到线程中。 

ThreadLocal的应用场合，我觉得最适合的是按线程多实例（每个线程对应一个实例）的对象的访问，并且这个对象很多地方都要用到。 

下面来看看ThreadLocal的实现原理（jdk1.5源码） 

Java代码  

1. public class ThreadLocal<T> {  
2.     /** 
3.      * ThreadLocals rely on per-thread hash maps attached to each thread 
4.      * (Thread.threadLocals and inheritableThreadLocals).  The ThreadLocal 
5.      * objects act as keys, searched via threadLocalHashCode.  This is a 
6.      * custom hash code (useful only within ThreadLocalMaps) that eliminates 
7.      * collisions in the common case where consecutively constructed 
8.      * ThreadLocals are used by the same threads, while remaining well-behaved 
9.      * in less common cases. 
10.      */  
11.     private final int threadLocalHashCode = nextHashCode();  
12.   
13.     /** 
14.      * The next hash code to be given out. Accessed only by like-named method. 
15.      */  
16.     private static int nextHashCode = 0;  
17.   
18.     /** 
19.      * The difference between successively generated hash codes - turns 
20.      * implicit sequential thread-local IDs into near-optimally spread 
21.      * multiplicative hash values for power-of-two-sized tables. 
22.      */  
23.     private static final int HASH_INCREMENT = 0x61c88647;  
24.   
25.     /** 
26.      * Compute the next hash code. The static synchronization used here 
27.      * should not be a performance bottleneck. When ThreadLocals are 
28.      * generated in different threads at a fast enough rate to regularly 
29.      * contend on this lock, memory contention is by far a more serious 
30.      * problem than lock contention. 
31.      */  
32.     private static synchronized int nextHashCode() {  
33.         int h = nextHashCode;  
34.         nextHashCode = h + HASH_INCREMENT;  
35.         return h;  
36.     }  
37.   
38.     /** 
39.      * Creates a thread local variable. 
40.      */  
41.     public ThreadLocal() {  
42.     }  
43.   
44.     /** 
45.      * Returns the value in the current thread's copy of this thread-local 
46.      * variable.  Creates and initializes the copy if this is the first time 
47.      * the thread has called this method. 
48.      * 
49.      * @return the current thread's value of this thread-local 
50.      */  
51.     public T get() {  
52.         Thread t = Thread.currentThread();  
53.         ThreadLocalMap map = getMap(t);  
54.         if (map != null)  
55.             return (T)map.get(this);  
56.   
57.         // Maps are constructed lazily.  if the map for this thread  
58.         // doesn't exist, create it, with this ThreadLocal and its  
59.         // initial value as its only entry.  
60.         T value = initialValue();  
61.         createMap(t, value);  
62.         return value;  
63.     }  
64.   
65.     /** 
66.      * Sets the current thread's copy of this thread-local variable 
67.      * to the specified value.  Many applications will have no need for 
68.      * this functionality, relying solely on the {@link #initialValue} 
69.      * method to set the values of thread-locals. 
70.      * 
71.      * @param value the value to be stored in the current threads' copy of 
72.      *        this thread-local. 
73.      */  
74.     public void set(T value) {  
75.         Thread t = Thread.currentThread();  
76.         ThreadLocalMap map = getMap(t);  
77.         if (map != null)  
78.             map.set(this, value);  
79.         else  
80.             createMap(t, value);  
81.     }  
82.   
83.     /** 
84.      * Get the map associated with a ThreadLocal. Overridden in 
85.      * InheritableThreadLocal. 
86.      * 
87.      * @param  t the current thread 
88.      * @return the map 
89.      */  
90.     ThreadLocalMap getMap(Thread t) {  
91.         return t.threadLocals;  
92.     }  
93.   
94.     /** 
95.      * Create the map associated with a ThreadLocal. Overridden in 
96.      * InheritableThreadLocal. 
97.      * 
98.      * @param t the current thread 
99.      * @param firstValue value for the initial entry of the map 
100.      * @param map the map to store. 
101.      */  
102.     void createMap(Thread t, T firstValue) {  
103.         t.threadLocals = new ThreadLocalMap(this, firstValue);  
104.     }  
105.   
106.     .......  
107.   
108.     /** 
109.      * ThreadLocalMap is a customized hash map suitable only for 
110.      * maintaining thread local values. No operations are exported 
111.      * outside of the ThreadLocal class. The class is package private to 
112.      * allow declaration of fields in class Thread.  To help deal with 
113.      * very large and long-lived usages, the hash table entries use 
114.      * WeakReferences for keys. However, since reference queues are not 
115.      * used, stale entries are guaranteed to be removed only when 
116.      * the table starts running out of space. 
117.      */  
118.     static class ThreadLocalMap {  
119.   
120.     ........  
121.   
122.     }  
123.   
124. }  

可以看到ThreadLocal类中的变量只有这3个int型： 

Java代码  

1. private final int threadLocalHashCode = nextHashCode();  
2. private static int nextHashCode = 0;  
3. private static final int HASH_INCREMENT = 0x61c88647;  

而作为ThreadLocal实例的变量只有 threadLocalHashCode 这一个，nextHashCode 和HASH_INCREMENT 是ThreadLocal类的静态变量，实际上HASH_INCREMENT是一个常量，表示了连续分配的两个ThreadLocal实例的threadLocalHashCode值的增量，而nextHashCode 的表示了即将分配的下一个ThreadLocal实例的threadLocalHashCode 的值。 

可以来看一下创建一个ThreadLocal实例即new ThreadLocal()时做了哪些操作，从上面看到构造函数ThreadLocal()里什么操作都没有，唯一的操作是这句： 

Java代码  

1. private final int threadLocalHashCode = nextHashCode();  

那么nextHashCode()做了什么呢： 

Java代码  

1. private static synchronized int nextHashCode() {  
2.     int h = nextHashCode;  
3.     nextHashCode = h + HASH_INCREMENT;  
4.     return h;  
5. }  

就是将ThreadLocal类的下一个hashCode值即nextHashCode的值赋给实例的threadLocalHashCode，然后nextHashCode的值增加HASH_INCREMENT这个值。 

因此ThreadLocal实例的变量只有这个threadLocalHashCode，而且是final的，用来区分不同的ThreadLocal实例，ThreadLocal类主要是作为工具类来使用，那么ThreadLocal.set()进去的对象是放在哪儿的呢？ 

看一下上面的set()方法，两句合并一下成为 

Java代码  

1. ThreadLocalMap map = Thread.currentThread().threadLocals;  

这个ThreadLocalMap 类是ThreadLocal中定义的内部类，但是它的实例却用在Thread类中： 

Java代码  

1. public class Thread implements Runnable {  
2.     ......  
3.   
4.     /* ThreadLocal values pertaining to this thread. This map is maintained 
5.      * by the ThreadLocal class. */  
6.     ThreadLocal.ThreadLocalMap threadLocals = null;    
7.     ......  
8. }  

再看这句： 

Java代码  

1. if (map != null)  
2.     map.set(this, value);  

也就是将该ThreadLocal实例作为key，要保持的对象作为值，设置到当前线程的ThreadLocalMap 中，get()方法同样大家看了代码也就明白了，ThreadLocalMap 类的代码太多了，我就不帖了，自己去看源码吧。 

写了这么多，也不知讲明白了没有，有什么不当的地方还请大家指出来。

• —软件人才免语言低担保 赴美带薪读研！—

Redis主从系统，除了做数据冗余，开可以做高可用性灾备。Reids提供了Sentinel工具来监控各Master的状态，如果Master异常，则会做主从切换，将slave作为master，将master作为slave。主从切换之后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变。master_redis.conf中会多了一句slaveof的配置，sentinel.conf的监控目标也随之调换，这一点要注意。

如果要监控两个redis实例，可以进行如下配置 sentinel.conf：

port 26379
daemonize yes
logfile "/var/log/redis/sentinel.log"

#master 7000
sentinel monitor master-7000 127.0.0.1 7000 2
sentinel down-after-milliseconds master-7000 30000
sentinel parallel-syncs master-7000 1
sentinel failover-timeout master-7000 180000

#master 7001
sentinel monitor master-7001 127.0.0.1 7001 1
sentinel down-after-milliseconds master-7001 30000
sentinel parallel-syncs master-7001 1
sentinel failover-timeout master-7001 180000

启动：

redis-sentinel sentinel.conf

[43023] 17 Jun 14:49:55.189 # Sentinel runid is 7b2f26a9633b9ec07f76ab6efba7508c235bf75d
[43023] 17 Jun 14:49:55.189 # +monitor master master-7000 1.0.0.1 7000 quorum 1
[43023] 17 Jun 14:49:55.189 # +monitor master master-7001 1.0.0.1 7001 quorum 1
[43023] 17 Jun 14:49:55.190 * +slave slave 1.0.0.2:7000 1.0.0.2 7000 @ master-7000 1.0.0.1 7000
[43023] 17 Jun 14:49:55.191 * +slave slave 1.0.0.2:7001 1.0.0.2 7001 @ master-7001 1.0.0.1 7001
[43023] 17 Jun 14:52:55.815 * +fix-slave-config slave 1.0.0.2:7000 1.0.0.2 7000 @ master-7000 1.0.0.1 7000
[43023] 17 Jun 14:52:55.816 * +fix-slave-config slave 1.0.0.2:7001 1.0.0.2 7001 @ master-7001 1.0.0.1 7001

需要注意的几个地方：

1、注意第一行最后一个2，意思是当有两个sentinel实例同时检测到redis异常时，才会有反应。

2、主从切换后，redis.conf、sentinel.conf内容都会改变，主要还想要原来的主从架构，要再修改配置文件；

3、master挂掉，sentinel已经选择了新的master，但是还没有将其改成master，但是已经将old master改成了slave。那么这时候如果重启old master，就会处于无主状态。所以一方面要等sentinel稳定后再启动old master，或者重新人工修改配置文件，重新启动集群。

4、sentinel只是在server端做主从切换，app端要自己开发，例如Jedis库的SentinelJedis，能够监控sentinel的状态。这样才能完整的实现高可用性的主从切换。

您可能也喜欢：
Redis Cluster的安装和配置（beta-6）	Redis集群增删节点的数据迁移问题	使用Jedis的ShardedJedis做Redis集群	Redis在新浪微博中的应用	Jedis sharding
无觅

原文请详见： http://www.ucai.cn/blogdetail/7036?mid=1&f=5

可以在线运行查看效果哦！

        本文根据优才网课程整理，面向web开发者，内容以实用为主，专业DBA可以绕行。

        如果你在大公司，可能有专门的DBA来做这些事情，如果你在一个小公司当架构师或者技术总监，或者你自己创业，那DBA的活你也得干了。咱们来讲一下基本的mysql安装和优化。

一： MYSQL安装和基本配置

在linux上安装，可以用包管理工具来安装，比较简单：

RedHat 系列：yum -yinstall  mysql mysql-server 

Debian系列：sudo apt-getinstall  mysql mysql-server

安装之后不知道mysql装到哪了怎么办，用whereis mysql 命令来找一下。先找到mysql的默认配置文件。一般来说，安装后有这么几个备选的配置：my-huge.cnf my-innodb-heavy-4G.cnf my-large.cnf my-medium.cnf my-small.cnf

就2014年的机器配置来说，咱们直接用my-huge.cnf。把my-huge.cnf 复制到/etc/下，改名my.cnf。配置文件就有了，然后启动mysql： /etc/init.d/mysqld start 。

安装之后默认的帐号是root, 密码为空。咱们要做的第一件事是改root密码。

进入mysql：mysql -uroot -p

选择数据库： use mysql

改密码： UPDATE user SET Password = PASSWORD('xxxx') WHERE user = 'root';

刷新权限： FLUSH PRIVILEGES;

现在数据库装好了，帐号和权限也设置了，是不是就可以使用了呢,还要检查几个配置。打开配置文件 vim /etc/my.cnf

skip-networking 要关闭。

bind-address = 127.0.0.1 这一行要关闭或者修改成允许的IP

skip-name-resolve 禁止dns解析，只能用IP连，这个可以打开。

       如果你的mysql经过一段时间运行，挺过了访问高峰，咱们再来检查一下配置是否合适。下面说的配置，都必须是在运行一段时间后检查才有意义。如果刚启动没多久，mysql的运行状态没有代表性，不能作为参考。检查配置参数也没意义。

二：连接数(connection)配置

       max_connections 可以设置最大并发连接数。当MySql的并发连接达到这个设定值时，新的连接将会被拒绝（“Can not connect to MySQL server. Too many connections”-mysql 1040错误，）。当发现MySql有能力处理更多的并发的时候， 建议调大这个值，相应给服务器带来更高的负载(CPU/IO/内存)。

查看设置的最大连接是多少：

mysql> show variables like 'max_connections';

+-----------------+-------+

| Variable_name   | Value |

+-----------------+-------+

| max_connections | 151   | 允许的最大连接数

+-----------------+-------+

 看当前连接数：showstatus like 'threads_connected';

最大连接数: show status like "max_used_connections";

如果max_used_connections已经接近 max_connections了，就说明max_connections太小。不合适了。

还有一些跟连接数相关的配置：

back_log=50

MySQL能暂存的连接数量。当主要MySQL线程在一个很短时间内得到非常多的连接请求，这就起作用。如果MySQL的连接数据达到max_connections时，新来的请求将会被存在堆栈中，以等待某一连接释放资源，该堆栈的数量即back_log，如果等待连接的数量超过back_log，将不被授予连接资源。

        back_log值指出在MySQL暂时停止回答新请求之前的短时间内有多少个请求可以被存在堆栈中。只有如果期望在一个短时间内有很多连接，你需要增加它，换句话说，这值对到来的TCP/IP连接的侦听队列的大小。

        不同的操作系统在这个队列大小上有它自己的限制。试图设定back_log高于你的操作系统的限制将是无效的。默认值为50。对于Linux系统推荐设置为小于512的整数。

如果链接数超过max_connections+back_log ，才会出错。

max_connect_errors=10

        当客户端连接服务端超时(超过connect_timeout), 服务端就会给这个客户端记录一次error，当出错的次数达到max_connect_errors的时候，这个客户端就会被锁定。除非执行FLUSH HOSTS命令。

connect_timeout=5

连接超时的秒数

三：查询缓存(query_cache)配置

       查询缓存就是内存中的一块存储区域，其存储了用户的SQL文本以及相关的查询结果。通常情况下，用户下次查询时，如果所使用的SQL文本是相同的，并且自从上次查询后，相关的纪录没有被更新过，此时数据库就直接采用缓存中的内容。从内存中读取要比从硬盘上速度要快好几百倍。MYSQL的查询缓存用于缓存select查询结果，并在下次接收到同样的查询请求时，不再执行实际查询处理而直接返回结果，有这样的查询缓存能提高查询的速度，使查询性能得到优化.

       要使用缓存，有几个条件：一是所采用的SQL语句是相同的。每次查询的语句不一样，肯定不能用到缓存。比如语句里带当前秒数 where ctime > xxx；二是表数据没有改过。没有改过结构，没有update，insert；三、客户端与服务器的默认字符集得一样。所以可以看出，要利用好缓存，有大量的相同的查询，而很少改变表里的数据，否则没有必要使用此功能。

查看查询缓存的设置：

SHOW VARIABLES LIKE '%query_cache%';
+------------------------------+----------+
| Variable_name                | Value    |
+------------------------------+----------+
| have_query_cache             | YES      |
| query_cache_limit            | 1048576  |  如果单个查询结果大于这个值，则不Cache
| query_cache_min_res_unit     | 4096    |  每次给QC结果分配内存的大小
| query_cache_size             | 33554432 |
| query_cache_type             | ON       |
| query_cache_wlock_invalidate | OFF      |
+------------------------------+----------+

query_cache_type=1

        如果设置为1，将会缓存所有的结果，除非你的select语句使用SQL_NO_CACHE禁用了查询缓存。如果设置为2，则只缓存在select语句中通过SQL_CACHE指定需要缓存的查询。query_cache_size 默认是32M，太小了，可调到128M或者256M。 可以通过Qcache_lowmem_prunes变量的值来检查是否当前的值满足你目前系统的负载。

        query_cache_size的工作原理：一个SELECT查询在DB中工作后，DB会把该语句缓存下来，当同样的一个SQL再次来到DB里调用时，DB在该表没发生变化的情况下把结果从缓存中返回给Client。这里有一个关建点，就是DB在利用Query_cache工作时，要求该语句涉及的表在这段时间内没有发生变更。那如果该表在发生变更时，Query_cache里的数据又怎么处理呢？

        首先要把Query_cache和该表相关的语句全部置为失效，然后在写入更新。那么如果Query_cache非常大，该表的查询结构又比较多，查询语句失效也慢，一个更新或是Insert就会很慢，这样看到的就是Update或是Insert怎么这么慢了。所以在数据库写入量或是更新量也比较大的系统，该参数不适合分配过大。而且在高并发，写入量大的系统，建系把该功能禁掉。 

       Qcache_lowmem_prunes可以检查是否设置的太小。query_cache_limit 默认是1M，根据你的常用查询的数据结果大小来定。如果返回的数据小，可以设置小一点。设置值大对大数据查询有好处，但如果你的查询都是小数据查询，就容易造成内存碎片和浪费。

查看缓存使用效果如何：

 showstatus like '%Qcache%';

 +-------------------------+----------+

| Variable_name           | Value    |

+-------------------------+----------+

| Qcache_free_blocks      | 160     | 目前还处于空闲状态的 Query Cache中内存 Block 数目，数目大说明可能有碎片。FLUSH QUERY CACHE会对缓存中的碎片进行整理，从而得到一个空闲块。

| Qcache_free_memory      | 23147296 | 缓存中的空闲内存总量。

| Qcache_hits             | 52349    | 缓存命中次数。

| Qcache_inserts          | 8827     | 缓存失效次数。

| Qcache_lowmem_prunes    | 0       | 缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看；如果这个数字在不断增长，就表示可能碎片非常严重，或者内存很少。

| Qcache_not_cached       | 2446     | 没有被cache和不适合进行缓存的查询的数量，通常是由于这些查询不是SELECT语句以及由于query_cache_type设置的不会被Cache的查询。show,use,desc

| Qcache_queries_in_cache | 5234     | 当前被cache的SQL数量。

| Qcache_total_blocks     | 10796   | 缓存中块的数量。

+-------------------------+----------+

show global status like 'Com_select'; 

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| Com_select    | 12592 | com_select 变量记录的是无缓存的查询次数+错误查询+权限检查查询。

+---------------+-------+

Mysql的查询缓存命中率没有官方算法，只有前人的经验总结

命中率≈ qcache_hits / (qcache_hits + com_select)

缓存碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100% ,如果碎片率太高，20% ，可以FLUSHQUERY CACHE整理缓存碎片，或者试试减小query_cache_min_res_unit，如果你的查询都是小数据量的话。

查询缓存利用率 = (query_cache_size – Qcache_free_memory) / query_cache_size * 100%

#查询缓存利用率在25%以下的话说明query_cache_size设置的过大，可适当减小;查询缓存利用率在80%以上而且Qcache_lowmem_prunes> 50的话说明query_cache_size可能有点小，要不就是碎片太多。

如何提高命中率：

1、字符集相同；2、SQL语句尽量固定(SQL语句避免随机数，秒数等)；3、 加大缓存空间； 4、适当分表,动静分离。

四、临时表缓存(tmp_table_size)配置

       mysql进行复杂查询或者 做高级GROUP BY操作的时候，系统为了优化查询，生成一些临时表。通过设置tmp_table_size选项来设置临时表占用空间的大小。我们使用explain分析SQL，如果在Extra列看到Using temporary就意味着使用了临时表。

        MySQL临时表分为“内存临时表”和“磁盘临时表”，其中内存临时表使用MySQL的MEMORY存储引擎，磁盘临时表使用MySQL的MyISAM存储引擎。一般情况下，MySQL会先创建内存临时表，但内存临时表超过配置指定的值后，MySQL会将内存临时表导出到磁盘临时表。临时表将在你连接MySQL期间存在。当你断开时，MySQL将自动删除表并释放所用的空间。

mysql> SHOW VARIABLES LIKE'%tmp_table_size%';
+----------------+----------+
| Variable_name  | Value   |
+----------------+----------+
| tmp_table_size | 33554432 | 
+----------------+----------+
1 row in set (0.00 sec)
mysql> show global status like'created_tmp%';
+-------------------------+----------+
| Variable_name           | Value    |
+-------------------------+----------+

| Created_tmp_disk_tables | 690421   |  服务器执行语句时在硬盘上自动创建的临时表的数量；

| Created_tmp_files       | 755473   | mysqld已经创建的临时文件的数量；

| Created_tmp_tables      | 14372959 | 服务器执行语句时自动创建的内存中的临时表的数量。如果Created_tmp_disk_tables较大，你可能要增加tmp_table_size值使临时 表基于内存而不基于硬盘；

+-------------------------+----------+

       每次创建临时表，Created_tmp_tables增加，如果临时表大小超过tmp_table_size，则是在磁盘上创建临时表，Created_tmp_disk_tables也增加,Created_tmp_files表示MySQL服务创建的临时文件文件数，比较理想的配置是：Created_tmp_disk_tables /Created_tmp_tables * 100% <= 25%

比如上面的服务器Created_tmp_disk_tables / Created_tmp_tables * 100% ＝1.20%，应该相当好了。默认大小是 32M，可调到64-256最佳，线程独占，太大可能内存不够I/O堵塞。

        跟临时表相关的另一配置是max_heap_table_size ，用户可以创建的独立的内存表所允许的最大容量.这个变量不适用与用户创建的内存表(memory table).SHOW VARIABLES LIKE'%max_heap_table_size%'; 咱们希望临时表是放到内存的。所以这个值设置的临时表缓存的空间一样就行。

（实际起限制作用的是tmp_table_size和max_heap_table_size的最小值。）如果临时表大于这两个的任何一个，都会存硬盘缓存：自动地把它转化为基于磁盘的MyISAM表，存储在指定的tmpdir目录下。

五、索引缓冲区（key_buffer_size）配置

        key_buffer_size是对MyISAM表性能影响最大的一个参数.key_buffer_size指定索引缓冲区的大小，它决定索引处理的速度，尤其是索引读的速度。通过检查状态值Key_read_requests和Key_reads，可以知道key_buffer_size设置是否合理。比例key_reads /key_read_requests应该尽可能的低，至少是1:100，1:1000更好。

       key_buffer_size只对MyISAM表起作用。即使你不使用MyISAM表，但是内部的临时磁盘表是MyISAM表，也要使用该值。可以使用检查状态值created_tmp_disk_tables得知详情。

mysql> show variables like'key_buffer_size';
+-----------------+----------+
| Variable_name   | Value   |
+-----------------+----------+
| key_buffer_size | 67108864 | 索引缓冲区的大小
+-----------------+----------+
show variables like 'key_cache_block_size';
mysql> show global status like 'key%';
+------------------------+------------+
| Variable_name          | Value      |
+------------------------+------------+

| Key_blocks_not_flushed | 0          |索引缓存内已经更改，但还没有清空到硬盘上的索引的数据块数量。

| Key_blocks_unused      | 0          | 索引缓存内未使用的块数量。你可以使用该值来确定使用了多少键缓存

| Key_blocks_used        | 53585      | 索引缓存内使用的块数量。该值为高水平线标记，说明已经同时最多使用了多少块。

| Key_read_requests      | 4952122733 | 一共有XXX个索引读取请求，

| Key_reads              | 11879      | 索引读取请求在内存中没有找到，直接从硬盘读取索引

| Key_write_requests     | 10508455   | 将索引的数据块写入缓存的请求数。

| Key_writes             | 6042774    |  将索引向硬盘写入数据块的物理写操作的次数。

+------------------------+------------+

比例key_reads /key_read_requests应该尽可能的低，至少是1:100，1:1000更好；

如果Key_reads太大,则应该把my.cnf中key_buffer_size变大.可以用Key_reads/Key_read_requests计算出cache失败率；

Key_writes/Key_write_requests：比例接近1较好。

       别人的经验是内存在4GB左右的服务器该参数可设置为384M或512M。可以自己算一下自己数据库的索引文件大小。注意：该参数值设置的过大反而会是服务器整体效率降低！

Cache命中比率：

1 - Key_reads / Key_read_requests 

Key buffer的使用率

100 – ( (Key_blocks_unused *key_cache_block_size) * 100 / key_buffer_size )

• —软件人才免语言低担保 赴美带薪读研！—

• —软件人才免语言低担保 赴美带薪读研！—

public class MyExceptionHandler implements HandlerExceptionResolver {  
    public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler,  
            Exception ex) {  
        Map<String, Object> model = new HashMap<String, Object>();  
        model.put("ex", ex);  
        // 根据不同错误转向不同页面  
        if(ex instanceof BusinessException) {  
            return new ModelAndView("error-business", model);  
        }else if(ex instanceof ParameterException) {  
            return new ModelAndView("error-parameter", model);  
        } else {  
            return new ModelAndView("error", model);  
        }  
    }  
}  

<bean id="exceptionHandler" class="cn.basttg.core.exception.MyExceptionHandler"/>

<error-page><exception-type>java.lang.Throwable</exception-type><location>/500.jsp</location></error-page><error-page><error-code>500</error-code><location>/500.jsp</location></error-page><error-page><error-code>404</error-code><location>/404.jsp</location></error-page>

• —软件人才免语言低担保 赴美带薪读研！—

Linode推出了比 Linode 2G 更低階的方案 Linode 1G：「 11th Linode Birthday / $10 Linode plan」。

先前的 2G 太大台了，大多數人根本用不到 (我的 blog 也才租 DigitalOcean的 512MB，然後開 swap file)。現在總算出了 1G 的版本，也許會有一些使用者回流吧，不過我覺得 Linode 的動作太慢了…

該來把東京的機器 downgrade 了…

Related Posts:

• DigitalOcean 與 Linode 的比較…
• Linode 提昇規格，並提供 SSD 方案…
• Linode 的 SSD 計畫…
• Linode 再升級：每個月多 USD$0.05，記憶體加倍…
• Linode 推出免費試用方案…