有一个很多人也许都不是很清楚的问题：i++或++i是一个原子操作吗？在上一节，其实已经提到了，在SMP（对称多处理器）上，即使是单条递减汇编指令，其原子性也是不能保证的。那么在单处理机系统中呢？
开发过程中，对于多线程多进程的并发和并行的几乎是编程不可避免的事情，特别在涉及对于数据进行修改或者添加的时候。这个时候就需要锁的出现，锁有多种类型，互斥锁，自旋锁。除了锁之外，我们还定义了原子操作，当然如果探究本质的话，原子操作也是有锁的，只不过是对汇编的操作锁。
非池化/池化内存如何分配的？该撸这块了，奈何到处都在调用PlatformDependent类的方法，要不各种判断，要不分配堆外内存。反正到处都能看到它，得，索性先把这个撸一把。PlatformDependent又依赖了PlatformDependent0，那就一层一层剥好了。
关于无锁队列的实现，网上有很多文章，虽然本文可能和那些文章有所重复，但是我还是想以我自己的方式把这些文章中的重要的知识点串起来和大家讲一讲这个技术。下面开始正文。
Postgresql中的大锁很多，其中ProcArrayLock和XactSLRULock使用了无锁队列优化（PG中XID的分发也可以用这种机制优化，高压场景下效果不错）。
如何保证一个进程或线程能安全稳定地把一段消息发送到另一个进程和线程，甚至是另一台机器的进程或线程，再或是要通过代理转发到另一个进程或线程，一直是一个比较麻烦的问题。
最近Rust For Linux的项目，随着Rust的火爆也开始逐渐升温，但是谷歌的强烈支持以及rCore OS、Redox等各种Rust操作系统项目的经验积累，Rust想进入到Linux的真正核心，也还是有很长的路要走，之前笔者已经撰文对于Rust在汇编支持、panic和alloc等系统操作等方面的问题进行过简要说明了。这里再对于Rust进入到Linux内核的最大拦路虎-也就是内存模型方面的问题，做一下介绍。
1. 引言 现代计算机，即使很小的智能机亦或者平板电脑，都是一个多核(多CPU)处理设备，如何充分利用多核CPU资源，以达到单机性能的极大化成为我们码农进行软件开发的痛点和难点。在多核服务器中，采用多进程或多线程来并行处理任务，俨然成为了大家性能调优的标准解决方案。多进程(多线程)的并行编程方式，必然要面对共享数据的访问问题，如何并发、高效、安全地访问共享数据资源，成为并行编程的一个重点和难点。 传统的共享数据访问方式是采用同步原语(临界区、锁、条件变量等)来达到共享数据的安全访问，然而，同步恰恰和
(1)队列的大小（m_lMaxQueueSize）应该足够的大，避免处理不过来时，找半天找不到空位置。
也就常说的单生产者-单消费者 的ringbuffer， 限制就是只能一个读线程（消费者），一个写进程（生产者）。
一个程序员在没有成长成为架构师之前，几乎都要跟 Bug为伴，程序员有很多时间都是花在了查找各种 Bug上。
活锁、死锁本质上是一样的，原因是在获取临界区资源时，并发多个进程/线程声明资源占用(加锁)的顺序不一致，死锁是加不上就死等，活锁是加不上就放开已获得的资源重试，其实单机场景活锁不太常见。举个例子资源A和B，进程P1和P2，
我们可以保证打印的global一定是2*20000000吗？答案是否定的。那为什么呢？
作者：juliatliu，腾讯 PCG 运营开发工程师 一、无锁队列用在什么样的场景？ 当需要处理的数据非常多，比如行情数据，一秒处理非常多的数据的时候，可以考虑用无锁队列。但是如果一秒只需要处理几百或者几千的数据，是没有必要考虑用无锁队列的。用互斥锁就能解决问题，数据量相对少的时候互斥锁与无锁队列之间差别并不是很明显。 二、为什么要用无锁队列？ 有锁队列会有哪些问题？ 1、Cache 的损坏，在线程间频繁切换的时候会导致 Cache 中数据的丢失； CPU 的运行速度比主存快 N 倍，所以大量的处理器时间
说到无锁，其实就是用cas，不过我在百度上搜java实现无锁队列的文章其实不多，所以自己用cas和volatile实现一下，线程安全那是必须的。
/*是old_val， reg替换为new_val，返回为true；否则返回为false*/
一、 引入 随着TIG阿基米德平台全面应用。组成京东容器生态技术栈的分布式域名解析服务ContainerDNS（go版https://github.com/tiglabs/containerdns ）全量生产环境应用，承载着每天百亿的访问量，单实例峰值每秒请求达到15W QPS，已经接近ContainerDNS的性能极限（17W QPS）。为了更好的提高系统的并发服务，对ContainerDNS 的优化也势在必行。 本文对ContainerDNS性能优化思考和技术实践历程，希望对业内在容器领域和域名解析方
对比两脚本的执行结果，lock-free是明显优于spin-lock的。接着从程序代码的差异上分析，lock-free在一条语句上（atomic_compare_exchange_weak(&count, &val, val+1)）完成了修改，而spin-lock则是“持有锁》修改值〉释放锁”。它们之间的差异可以由下两图体现：
1、面试跑不掉。现在只要面试Java相关的岗位，肯定或多或少会会涉及JDK源码相关的问题。
曾经有个人，问我对无锁队列的实现是怎么想的。我想了一会儿，还是纳闷儿，无锁，也能做消息队列吗？然后他让我回去好好查查。没错，他就是面试官。
1.普通队列：先进先出。 2.带优先级的：（优先队列：本质上是二叉树）按照顺序进，出队列的时候出优先级最高的元素，如果优先级相同，再按照先进先出的方式。 3.带类型的：业务上的类型，与具体场景密切相关，入队列按照原来的顺序入，出队列按照类型取数据，相同类型元素再先进先出。 4.阻塞队列：线程安全版本队列（当队列为空，再去取元素就会发生阻塞；当队列为满，再去插入元素也会发生阻塞） 5.无锁队列：线程安全版本队列，不用管锁就能保证线程安全。
Disruptor是LMAX公司开源的一个高效的内存无锁队列。这两天看了一下相关的设计文档和博客，下面尝试进行一下总结。 第一部分。引子 谈到并发程序设计，有几个概念是避免不了的。 1.锁：锁是用来做并发最简单的方式，当然其代价也是最高的。内核态的锁的时候需要操作系统进行一次上下文切换，等待锁的线程会被挂起直至锁释放。在上下文切换的时候，cpu之前缓存的指令和数据都将失效，对性能有很大的损失。用户态的锁虽然避免了这些问题，但是其实它们只是在没有真实的竞争时才有效。下面是一个计数实验中不加锁、使用锁、使用CA
lock free (中文一般叫“无锁”，一般指的都是基于CAS指令的无锁技术) 是利用处理器的一些特殊的原子指令来避免传统并行设计中对锁(lock)的使用。
无锁编程，即通过CAS原子操作去控制线程的同步。如果你还不知道什么使CAS原子操作，建议先去查看相关资料，这一方面的资料网络上有很多。
RCU是Linux 2.6内核系统新的锁机制 RCU(Read-Copy Update)。参考：http://www.ibm.com/developerworks/cn/linux/l-rcu/
多线程编程是多CPU系统在中应用最广泛的一种编程方式，在传统的多线程编程中，多线程之间一般用各种锁的机制来保证正确的对共享资源（share resources）进行访问和操作。
高性能和高并发，听着就有点类似，并且他们还经常一起提及，比如提高我们的并发性能，显然，高性能可以提高我们的并发，但是细化来看，他们是有区别的，他们的考量点的维度不同。高性能需要我们从单机维度到整体维度去考虑，更多的是先从编码角度、架构使用角度去让我们的单机（单实例）有更好的性能，然后再从整个系统层面来拥有更好的性能；高并发则直接是全局角度来让我们的系统在全链路下都能够抗住更多的并发请求。
「CAS」(Compare And Swap) 是一种无锁算法的实现手段，中文名称为比较并交换。它由 CPU 的原子指令实现，可以在多线程环境下实现无锁的数据结构。
numpy-ml 是一个使用 NumPy 实现的机器学习算法集合，尽管效率不高但相对易读。该项目的主要功能包括提供各种模型和工具函数来支持机器学习任务。
今天我们来研究学习一下AbstractQueuedSynchronizer类的相关原理，java.util.concurrent包中很多类都依赖于这个类所提供队列式同步器，比如说常用的ReentranLock，Semaphore和CountDownLatch等。
本文整理了Single Producer/Consumer lock free Queue step by step这篇文章里头关于高性能的SPSC无锁队列使用遵循的四个原则：
为什么需要原子性操作？ 我们考虑一个例子： （1）x++这个常见的运算符在内存中是怎样操作的？ 从内存中读x的值到寄存器中，对寄存器加1，再把新值写回x所处的内存地址 若是有两个线程同时对同一个变量++，就会出现问题，如下： time Thread 1 Thread 2 0 load eax, x 1 load eax, x 2 add eax, 1 3 add eax, 1 4 s
最近想解决下MyCat开统计后TPS吞吐量总上不去的问题，于是想起了Disruptor这个东西。之前想研究过，但是，由于当时并不太需要，而且感觉官方示例比较怪异，就是知道他比较快，没有想用。现在捡起来好好研究下。 首先，推荐大家并发编程网的Disruptor译文. 官网的翻译，翻译的不错，从硬件到软件，谈了Disruptor相对于传统阻塞队列的优化。这里主要针对源代码谈实现和应用。 首先，先拿一张图看一下Disruptor的主要元素：
转载自 https://blog.csdn.net/AJ1101/article/details/81711812
Disruptor 是英国外汇交易公司 LMAX 开发的一个高性能队列，研发的初衷是解决内存队列的延迟问题，因其出色的性能表现获得 2011 Duke’s 程序框架创新奖。
最近一直在研究队列的一些问题，今天楼主要分享一个高性能的队列 Disruptor 。
并发编程中，锁带解决了安全问题，同时也带来了性能问题，因为锁让并发处理变成了串行操作，所以如无必要，尽量不要显式使用锁。
我们清楚使用锁的性能比较低，尽量使用无锁设计。接下来就我们来认识下Disruptor。
锁是高性能程序的杀手，但是为了保证数据的一致性，在多线程的应用环境下又不得不加锁。但是在某些特殊的场景下， 是可以通过优化数据结构来达到无锁的目的。那么我们就来看一下如何实现一个无锁队列。 队列：众所周知，就是先进先出。 出队列的时候从队列头取出一个结点；入队列的时候，将结点添加到队列尾部。当多线程同时操作一个队列读写时，显然就需要加锁。但是在单读单写的这种多线程应用时，是可以做到无锁的。直接上代码 #ifndef _QUEUE_H_ #define _QUEUE_H_ template<class T>
环形缓冲区支持队列管理。rte_ring并不是具有无限大小的链表，它具有如下属性：
作者 | CloudWeGo Rust Team GitHub | https://github.com/bytedance/monoio 一、概述 尽管 Tokio 目前已经是 Rust 异步运行时的事实标准，但要实现极致性能的网络中间件还有一定距离。为了这个目标，CloudWeGo Rust Team 探索基于 io-uring 为 Rust 提供异步支持，并在此基础上研发通用网关。 本文包括以下内容： 介绍 Rust 异步 Runtime； Monoio 的一些设计精要； Runtime 对
https://juejin.im/post/5b5f10d65188251ad06b78e3
作 者 jacowu 腾讯后台开发 高级工程师 商业转载请联系腾讯WeTest获得授权，非商业转载请注明出处。 WeTest 导读 Seastar是一个优秀的c++网络框架，代码量低，注释详细，可读性高，在一些基础部门已经开始应用。框架之中有很多美的地方值得我们学习，本文主要介绍了Seastar框架的代码之美和一些关键特性。 对于代码之美是站在C++程序员的角度来看的，比如haskell程序员看到这样的代码，也许会感叹：“Pieceofsh**！”。 学习不同的语言，不同的框架，用不同的方法解决问题，可以
上一篇文章中，我们介绍了 Log4j2 异步日志的实现 -- AsyncAppender：
早在96年就有论文提出了无锁队列的概念，再到后来 Disruptor，高性能已得到生产的验证。此处介绍的 Jctools 中的高性能队列，其性能丝毫不输于 Disruptor。
无锁队列适用场景： 两个线程之间的交互数据， 一个线程生产数据， 另外一个线程消费数据，效率高 缺点：需要使用固定分配的空间，不能动态增加／减少长度，存在空间浪费和无法扩展空间问题 package main import ( "fmt" "reflect" "strings" "time" ) type LoopQueue struct{ start int end int length i
本来看到Android的ndk都开始用gcc4.8和gcc4.9了，而且gcc4.8.1开始支持全部的c++11的特性，我就很happy地用上了。结果出现这么个错误。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
