-
Java并发学习 ConcurrentLinkedQueue以及被魔改的M&S算法
前面分析了FutureTask，一个同步器，下面分析一个经典的数据结构：队列。并发环境下的队列实现有很多，针对的问题和使用场景也有所不同。这里分析一个比较基础的lock free unbounded queue：ConcurrentLinkedQueue。 按照《the art of multiprocessor programming》里的定义，ConcurrentLinkedQueue属于total类型。即enqueue与dequeue不会阻塞。不阻塞就代表这个类不需要考虑同步器需要考虑的逻辑，专注于数据结构本身的实现上。 注意，本文并不会详细介绍M&S，也就是Michael & Scott算法，如果你有兴趣，请自行阅读论文 Michael, Maged M., and Michael L. Scott. Simple, fast, and practical non-blocking and blocking concurrent queue algorithms. No. TR-600. ROCHESTER UNIV NY DEPT OF COMPUTER SCIENCE, 1995. 或者《the art of multiprocessor programming》第10章。 ConcurrentLinkedQueue在注释中提到自己是M&S的变体，但是当你看了核心代码offer与poll（分别对应enqueue与dequeue）之后你不会认为这是个变体，因为改得面目全非了。M&S算法最有名的helping在offer没有直接体现，enqueue时的二次CAS被改成了一次，最让人不可思议的是tail可以在某种情况下指向head之前的节点，也就是说数据结构，甚至queue本身的不变条件都被修改了。所以如果你想分析ConcurrentLinkedQueue的话，建议把M&S算法放在一边，以一种新算法的角度来分析和阅读。
-
Java并发学习 类FutureTask分析与改进
大约两个月没有写博客了，原因是最近自己一直在看《The Art of Multiprocessor Programming》。这本书从理论到实践介绍了多核编程，给出的数据结构和算法都有相应的论文。如果你想好好学习多核编程，而不是某种语言的并发机制介绍的话，非常推荐这本书。同时这本书里介绍的算法，在Java的并发库里面都能找到影子。作为继续深入学习的一部分，个人打算逐个分析典型的并发类，并且基于个人理解给出一些改进或者变化。 Java的并发库里面，从版本1.5（Java 5）开始引入了接口Future和实现类FutureTask。与其他Synchronizer（同步类）不同，FutureTask并没有依赖AQS，所以是相对简单的一个并发类。FutureTask包含执行Task和同步结果两块主要功能。这里主要分析如何同步结果。 注意，本文并不会逐行代码分析FutureTask。为了学习如何设计并发类，本文以个人理解的原型类开始，逐渐修改成为接近实际FutureTask甚至超过FutureTask的代码。
-
给开始在日本学习生活的人的一点参考：在日本看病（2）
上篇大致讲了一下在日本看病的常识。小毛小病在诊所能解决掉是最好的，不过有些必须去医院，比如我昨天做的拔智齿的手术。 本文主要是记录自己拔智齿的前后过程，顺带讲一下医院与诊所的不同。 前篇中也提到过，如果直接去医院，也就是是紹介状なし（しょうかいじょうなし，没有介绍信）的情况下去的话，会收额外的一笔不少的费用。所以建议先在诊所看病，如果不行的话，可以让诊所开介绍信，你再去医院。 这次我就是親知らずの抜歯（おやしらずのばっし、拔智齿），需要动手术，歯科（しか、牙科）帮忙开了介绍信。注意开介绍信也是要费用的，但是比没介绍信直接去医院要便宜。我拿到的介绍信是一个信封，上面给你指定了医院，科室和医生。信封里面的内容我没有确认，估计就是你在这家诊所的病例卡。
-
给开始在日本学习工作的人的一点参考：在日本看病（1）
最近到医院预约了拔智齿，突然想到对于一个到了人生地不熟的日本，而且不喜欢抱团的人来说，如何在日本学习或者工作的同时看病是一个很大的难题。语言是一方面，日本和国内大相径庭的看病方式也需要时间适应。所以，考虑了下，分享顺便也记录下自己的看病经历。 到现在为止，个人经历过的主要是皮肤科（皮膚科、ひふか），牙医（歯科、しか）。个人体质原因，不大感冒，没去过耳鼻咽喉科（耳鼻咽喉科、じびいんこうか）。不过今年春天好像得了花粉症（花粉症、かふんしょう），可能之后会去。 和国内不同，小毛小病这边不会去医院（病院、びょういん），而是先去诊所（クリニック）。直接去医院的话，会额外收一笔费用，而且你会等很长时间。
-
登山笔记・关于登山
随便聊一下「登山」这个概念。 比如说珠穆朗玛（8848m）和上海佘山（100m）同样是山，但爬这两座山是完全两个概念。 日语环境里，「登山（とざん）」是个大概念，去高尾山（599m）也是登山，去富士山（3776m）也是登山。 之前心血来潮查过知乎，好像在中国国内，普遍把徒步和登山的概念以山的高度作为区分，4km以上算登山但4km以下就只能划作徒步。不是很清楚这样划分的意义，但这种划分总让人觉得登山是专业的事情，不是普通人可以做的，门槛很高。 在日语环境下，登山便没有那么高的门槛。原先我也有芥蒂，都说自己是去徒步（hiking），同事们却听得一愣一愣的，反问你不是去登山了吗。后来想想确实没必要在自己内部划分这些，开心就好。 纵走（縦走）也好，徒步（ハイキング）也好，trekking（トレッキング）也好，划分的那么清楚自己心也累。 反正就是早起赶早班电车电车下来开始走，走到目的地偶尔住一天，绝大多数时候是休息片刻便立即动身，下山或者走向另一个山头。 回程累了电车上偶尔小睡30分钟。 回家泡个澡倒头就睡做个还在山上走的梦。 第二天起来享受着肌肉酸痛重新回归毫无偏离的日常生活。
-
自适应分布式速率限制（distributed rate limiter）
本文是针对xratelimiter的算法说明。 https://github.com/xnnyygn/xratelimiter 首先对rate limiter做一下简单介绍。 rate limiter主要用在限流，比如希望网站的访问在一定的量的时候，对于API有调用量限制，作为云服务商限制访问用户网站的流量等等。 常见的rate limiter算法有token bucket。具体算法这里不作展开。一般实现中，会有一个记录最后添加了token的时间戳，还有一个记录当前token数的变量。由于有两个变量，在使用redis实现集中式的token bucket时无法原子修改。
-
基于GOSSIP的集群成员管理-失败检测
本文是对于以下项目的算法说明。 https://github.com/xnnyygn/xgossip 失败检测即Failure Detection，在xgossip中主要是指由于网络或者节点当机问题导致无法正常通讯的问题的检测。除此之外，检测到之后系统如何处理也是需要根据实际需求来决定的。以下主要针对这两方面进行讲解。
-
基于GOSSIP的集群成员管理-成员的加入和退出
本文是对于以下项目的算法说明。 https://github.com/xnnyygn/xgossip 首先简单介绍一下GOSSIP。 GOSSIP据说最早见于论文《Epidemic Algorithms for Replicated Database Maintenance》，对于GOSSIP有兴趣的人建议阅读一下此论文。 GOSSIP算法如论文标题是一种epidemic algorithm，可以理解为传染病的传播。有三个人A，B，C。A是传染源，当A传染给B，B传染给C之后，所有人都被传染了。在分布式系统中，可以把传染病类比为更新，当所有参与的节点都获取到了更新之后，集群达到最终一致状态。从这个角度来说，GOSSIP是一种弱一致性，或者说最终一致性算法。
-
Raft实现笔记-日志结构
本系列是在实现了绝大部分raft论文中描述的功能之后实现过程中遇到的问题，设计的决策等的记录。随着功能的增减，项目的逐渐完善，系统中的实现笔记可能会有偏差，但是基本上对于第一次实现或者想要理解raft的人来说可以作为一个参考。 本篇是针对0.1.0版本xraft，0.1.0之后的版本可能会有所变化。
-
登山笔记（序）向山进发
从小到大没爬过几次山。 印象里最深的是小时候春秋游去过南昌梅岭和三清山，高中时浙江仙居上海佘山和大学里暑期调研的泰山。但这些都是旅游景点并非所谓的山，我甚至说不出这些景点内山的名字。想去爬山玩？门票价格摆在那里。所以从来没有对登山产生过兴趣。 然而看过ヤマノススメ后才知道在日本登山是用不收门票钱的。 刚来日本半年后某个周末的上午躺在地上，想想自己一个人平时周末除了打游戏就是看动画，不如出去走走。然后就穿上普通运动鞋和轻便的服装开始了场圣地巡礼。 高尾山，来日本旅游的话绝对推荐去走一圈的山，在东京都内交通方便。没有登山装备可以简单从一号路的水泥路上去，想体验水路的可以走走六号路。 高尾山附近一带大多是这类泥地的山，适合散心。想稍微锻炼一下体力的则可以往丹沢箱根方向走。 不知不觉已经走过了很多地方，不知不觉买了一堆户外用品。留下一堆遗憾和一堆回忆。 不知道什么时候能去長野県来一圈纵走，或者在山上搭个帐篷看星空。如果养了阿猫阿狗的话，好想带着它们去爬山。 爬山回来后洗个澡睡的像猪一样，闭上眼睛就能看到满是石头的地面，好像还在摇头晃脑走着山路一样。 希望今年能在富士山上看到御来光。