最近我们看到各种各样新的工具，能够帮助你搞定日志。开源的项目如Scribe和LogStash，在线的工具如Splunk，托管的服务如Sumologic和PaperTrail。这些工具可以帮你减少大量日志数据。
但是有一个东西它们都无法帮到你，它们都依赖你实际放入日志中的数据。获得更多、更高质量数据的任务就落在你身上了。所以，在关键时刻你需要调试部分代码和丢失的日志数据，你可能要取消晚饭了。
为了减少以上情况发生的次数，我要给你分享5件事情，当你在生产环境使用日志的时候你必须紧记在心： 阅读全文
自旋锁和互斥锁是多线程程序中的重要概念。 它们被用来锁住一些共享资源， 以防止并发访问这些共享数据时可能导致的数据不一致问题。 但是它们的不同之处在哪里？ 我们应该在什么时候用自旋锁代替互斥锁？
理论分析
从理论上说， 如果一个线程尝试加锁一个互斥锁的时候没有成功， 因为互斥锁已经被锁住了， 这个未获取锁的线程会休眠以使得其它线程可以马上运行。 这个线程会一直休眠， 直到持有锁的线程释放了互斥锁， 休眠的线程才会被唤醒。 如果一个线程尝试获得一个自旋锁的时候没有成功， 该线程会一直尝试加锁直到成功获取锁。 因此它不允许其它线程运行(当然， 操作系统会在该线程所在的时间片用完时， 强制切换到其它线程)。 阅读全文
《Concurrent Data Structures》（并发数据结构）一文是Mark Moir和Nir Shavit所撰写的一篇有关并发数据结构的综述性文章。这篇文章从多核处理器基础开始，理清了并发数据结构的基础设计理念和技巧，介绍了数据结构算法相关的正确性证明，并列举了栈，链表，队列，树等常用并发数据结构的设计思路。
为了促进大家对并发数据结构基础概念的了解，并发编程网组织译者翻译该论文。由于时间仓促，如有不到位的地方，还请各位指出。
感谢下列译者：董明鑫，俞升兵，Noodles，张军，huavben，iDestiny，郭振斌 阅读全文
感谢同事【沐剑】的投稿
在大规模互联网应用中，负载均衡设备是必不可少的一个节点，源于互联网应用的高并发和大流量的冲击压力，我们通常会在服务端部署多个无状态的应用服务器和若干有状态的存储服务器（数据库、缓存等等）。
负载均衡设备的任务就是作为应用服务器流量的入口，首先挑选最合适的一台服务器，然后将客户端的请求转发给这台服务器处理，实现客户端到真实服务端的透明转发。最近几年很火的「云计算」以及分布式架构，本质上也是将后端服务器作为计算资源、存储资源，由某台管理服务器封装成一个服务对外提供，客户端不需要关心真正提供服务的是哪台机器，在它看来，就好像它面对的是一台拥有近乎无限能力的服务器，而本质上，真正提供服务的，是后端的集群。
一个典型的互联网应用的拓扑结构是这样的：
感谢同事 ｛空蒙｝的投稿
最近碰到个场景，还蛮有普遍性的，如mtop的请求入口非常多，有api2，api3，api4，h5，h5update，cdn_cache,bigpipe等，而Mtop需要依据其具体的入口，选择不同的业务逻辑进行对应的处理。
马上想到两个方案：
考虑支持插入，删除和查找操作的并发数据结构实现。如果这些操作只处理键值（译者注：而不处理具体值），这样的数据结构会是一个集合。如果一个数据值与每一个键关联起来，我们就得到了一部数据字典。由于他们都是密切相关的数据结构，一个并发的集合通常能够经过适当修改来实现一部字典。在接下来的三个小节中，我们将专注于利用linked lists，hash tables，和trees这三种不同的数据结构来实现集合。
实现高效并发栈和队列的大部分挑战来自于一个被插入的元素可以被删除这一需求。并发池是一种支持插入和删除操作的数据结构，它允许删除操作移除任何一个已经被插入的，并且没有在随后被删除的元素。这样的弱需求提供了提高并发性能的机会。
一个高效的并发池可以使用任意静态一致的计数器来构建。在这样的并发池中，元素被置于数组当中，fetch-and-inc操作决定插入操作在哪个位置存储元素，同样的，fetch-and-inc操作决定删除操作在哪个位置获得元素。每一个数组元素都包含了一个表示满/空的比特位或者等效的机制，来表明在相应的位置，将要删除的元素已经存在。在这种策略下，使用combining tree，combining funnel，counting network，diffracting tree中的任何一个技术都可以并行化共享技术器，解决这一主要的瓶颈来创建出一个高吞吐量的共享并发池。此外，一个类似栈的池可以使用一个允许增加和减少操作的计数器来实现，然后利用以上技术中的一种来并行化.
阅读全文
感谢同事【沐剑】的投稿
重排序通常是编译器或运行时环境为了优化程序性能而采取的对指令进行重新排序执行的一种手段。重排序分为两类：编译期重排序和运行期重排序，分别对应编译时和运行时环境。
在并发程序中，程序员会特别关注不同进程或线程之间的数据同步，特别是多个线程同时修改同一变量时，必须采取可靠的同步或其它措施保障数据被正确地修改，这里的一条重要原则是：不要假设指令执行的顺序，你无法预知不同线程之间的指令会以何种顺序执行。
但是在单线程程序中，通常我们容易假设指令是顺序执行的，否则可以想象程序会发生什么可怕的变化。理想的模型是：各种指令执行的顺序是唯一且有序的，这个顺序就是它们被编写在代码中的顺序，与处理器或其它因素无关，这种模型被称作顺序一致性模型，也是基于冯·诺依曼体系的模型。当然，这种假设本身是合理的，在实践中也鲜有异常发生，但事实上，没有哪个现代多处理器架构会采用这种模型，因为它是在是太低效了。而在编译优化和CPU流水线中，几乎都涉及到指令重排序。 阅读全文
任何查找树的并发实现都可以通过用一个独占锁保护来完成。通过使用读写锁对并发性能有一定提升，读写锁允许所有只读（查找）操作并发地执行，因为读操作是以共享模式持有锁，然而更新（插入或删除）操作持有独占模式的锁，从而排斥其他所有操作。如果更新操作比较少，这还能接受，但是只要有适量的更新操作，那么更新操作所持有的独占锁将产生线性的瓶颈，从而大大降低性能。通过使用细粒度的锁策略——比如每个节点一个锁，而不是整棵树使用同一个锁——这样我们进一步地提升了并发性能。
阅读全文
典型可扩展的哈希表即一个可调整大小的桶数组(buckets), 每一个桶存放预期数量的元素，因此哈希表平均在常量时间内进行插入，删除，查询操作。哈希表调整大小的主要成本—–在于新旧桶(buckets)之间进行重新分配操作，该操作被分摊到所有表操作上，所以平均操作时间也是常量的。哈希表调整大小就是扩容，在实践中，哈希表仅需要增加数组大小即可。
Michael实现了一个可并发，不可扩展的哈希表(通过对哈希表中每个桶进行读写锁约束)。然而，为了保证元素数量增长时的性能，哈希表必须可扩展。
阅读全文
感谢同事[空蒙]的投稿。
首先感谢@烈元一起排查此问题。今天发现线上一台机器，监控一直在告警，一看是健康检查不通过，就上去查看了下，首先自己curl了下应用的url，果然是超时没有响应，那就开始按顺序排查了：
1、 load非常低，2、gc也正常，3、线程上也没死锁，4、日志一切正常。那是什么情况呢，不能忘记网络啊。果然，netstat命令一把，结果如下：
TIME_WAIT 68 CLOSE_WAIT 194 ESTABLISHED 3941 SYN_RECV 100
问题出来了，SYN_RECV竟然达到100个，正常情况下，半连接的请求应该是很小的。而且我们机器是内部的，不是lvs，不太会有半连接攻击，怎么可能达到这么大呢？
感谢同事【空蒙】的投稿
之前看了java8的longadder实现，最近又看到一篇文章介绍longadder实现的。其实现思路也是分段，最后需要get的时候，再进行sum计算。其核心思路就是减少并发，但之前老的Atomic，难道就没有提升的空间了吗？昨晚进行了一次测试。测试代码如下：
本文首发于InfoQ 作者：方腾飞 校对：张龙
在并发编程中使用生产者和消费者模式能够解决绝大多数并发问题。该模式通过平衡生产线程和消费线程的工作能力来提高程序的整体处理数据的速度。
在线程世界里，生产者就是生产数据的线程，消费者就是消费数据的线程。在多线程开发当中，如果生产者处理速度很快，而消费者处理速度很慢，那么生产者就必须等待消费者处理完，才能继续生产数据。同样的道理，如果消费者的处理能力大于生产者，那么消费者就必须等待生产者。为了解决这种生产消费能力不均衡的问题，所以便有了生产者和消费者模式。
生产者消费者模式是通过一个容器来解决生产者和消费者的强耦合问题。生产者和消费者彼此之间不直接通讯，而通过阻塞队列来进行通讯，所以生产者生产完数据之后不用等待消费者处理，直接扔给阻塞队列，消费者不找生产者要数据，而是直接从阻塞队列里取，阻塞队列就相当于一个缓冲区，平衡了生产者和消费者的处理能力。
阅读全文
Loading...
(4 votes, average: 4.25 out of 5)
