高并发可以不加锁吗

最近遇到别人问的一个问题，如下：

    高并发下修改商品库存，加锁会导致性能问题，怎样实现在不加锁的情况下实现高性能修改库存？

我的答案：

1、一般对于并发处理都需要加锁，否则会导致共享变量不可见问题，尽量将锁的力度变小

2、如果确认不能或不想加锁，则做串行化处理，我给的解决方案是消息队列

3、http://www.zhihu.com/question/36560619 这里有说单生产者和单消费者 的队列是可以做到真正无锁，看不懂

4、http://zhidao.baidu.com/link?url=qDk1lJax-3v08Bng7Ignf8Zk4gVwUAr0118lzm3lRqTiaBpbe5j5x6f9V8yBpoq5zulHudZb7X3pRs8X51Xxlz80VrgskxMaTjyGklUmZ2e

这篇文章也说了做串行化处理，消息队列的线程不做IO操作，而是单独开线程从消息队列取数据进行IO操作

结论：

问我问题的人说已经找到了不加锁，不用消息队列解决问题的方法，但是不告诉我。。。

来自为知笔记(Wiz)

时间： 2024-12-13 18:48:50

高并发可以不加锁吗的相关文章

【高并发】优化加锁方式时竟然死锁了！！

写在前面 今天,在优化程序的加锁方式时,竟然出现了死锁!!到底是为什么呢?!经过仔细的分析之后,终于找到了原因. 为何需要优化加锁方式? 在<[高并发]高并发环境下诡异的加锁问题(你加的锁未必安全)>一文中,我们在转账类TansferAccount中使用TansferAccount.class对象对程序加锁,如下所示. public class TansferAccount{ private Integer balance; public void transfer(TansferAccoun

【高并发】高并发环境下诡异的加锁问题（你加的锁未必安全）

声明 特此声明:文中有关支付宝账户的说明,只是用来举例,实际支付宝账户要比文中描述的复杂的多.也与文中描述的完全不同. 前言 很多网友留言说:在编写多线程并发程序时,我明明对共享资源加锁了啊?为什么还是出问题呢?问题到底出在哪里呢?其实,我想说的是:你的加锁姿势正确吗?你真的会使用锁吗?错误的加锁方式不但不能解决并发问题,而且还会带来各种诡异的Bug问题,有时难以复现! 在上一篇<[高并发]如何使用互斥锁解决多线程的原子性问题?这次终于明白了!>一文中,我们知道在并发编程中,不能使用多把锁保护

高并发的情况下，如果处理大量请求修改同一样变量，用copy不用加锁。

modif_dict = {'name': None, 'age':None} 假如上面的数据是一个大量并发读取并修改的数据 modif_dicf['name'] = 'xiaom' modif_dict['age'] = 18 像上面这样的数据有大量的请求写入,为了防止高并发时数据重复写入,数据出现问题. 可以在前面添加 param = modif_dicy.copy() param['name'] = 'xiaobai' param['age'] = 20 如果从我的角度理解,因为使用了co

探索 ConcurrentHashMap 高并发性的实现机制

简介 ConcurrentHashMap 是 util.concurrent 包的重要成员.本文将结合 Java 内存模型,分析 JDK 源代码,探索 ConcurrentHashMap 高并发的具体实现机制. 由于 ConcurrentHashMap 的源代码实现依赖于 Java 内存模型,所以阅读本文需要读者了解 Java 内存模型.同时,ConcurrentHashMap 的源代码会涉及到散列算法和链表数据结构,所以,读者需要对散列算法和基于链表的数据结构有所了解. Java 内存模型 由

高并发的核心技术-幂等的实现方案（转）

高并发的核心技术-幂等的实现方案 一.背景 我们实际系统中有很多操作,是不管做多少次,都应该产生一样的效果或返回一样的结果. 例如: 1. 前端重复提交选中的数据,应该后台只产生对应这个数据的一个反应结果. 2. 我们发起一笔付款请求,应该只扣用户账户一次钱,当遇到网络重发或系统bug重发,也应该只扣一次钱: 3. 发送消息,也应该只发一次,同样的短信发给用户,用户会哭的: 4. 创建业务订单,一次业务请求只能创建一个,创建多个就会出大问题. 等等很多重要的情况,这些逻辑都需要幂等的特性来支持.

数据量下高并发同步的讲解（不看，保证你后悔

4.常见的提高高并发下访问的效率的手段 首先要了解高并发的的瓶颈在哪里? 1.可能是服务器网络带宽不够 2.可能web线程连接数不够 3.可能数据库连接查询上不去. 根据不同的情况,解决思路也不同. 像第一种情况可以增加网络带宽,DNS域名解析分发多台服务器. 负载均衡,前置代理服务器nginx.apache等等 数据库查询优化,读写分离,分表等等 最后复制一些在高并发下面需要常常需要处理的内容: 尽量使用缓存,包括用户缓存,信息缓存等,多花点内存来做缓存,可以大量减少与数据库的交互,提高性能.

转---高并发Web服务的演变——节约系统内存和CPU

[问底]徐汉彬:高并发Web服务的演变——节约系统内存和CPU 发表于22小时前| 4223次阅读| 来源CSDN| 22 条评论| 作者徐汉彬 问底Web服务内存CPU并发徐汉彬 摘要:现在的Web系统面对的并发连接数在近几年呈现指数增长,高并发成为了一种常态,给Web系统带来不小的挑战.一味地通过增加机器来解决并发量的增长,成本是非常高昂的.结合技术优化方案,才是更有效的解决方法. [导读] 徐汉彬曾在阿里巴巴和腾讯从事4年多的技术研发工作,负责过日请求量过亿的Web系统升级与重构,目前在小

mysql处理高并发，防止库存超卖

先来就库存超卖的问题作描述:一般电子商务网站都会遇到如团购.秒杀.特价之类的活动,而这样的活动有一个共同的特点就是访问量激增.上千甚至上万人抢购一个商品.然而,作为活动商品,库存肯定是很有限的,如何控制库存不让出现超买,以防止造成不必要的损失是众多电子商务网站程序员头疼的问题,这同时也是最基本的问题. 从技术方面剖析,很多人肯定会想到事务,但是事务是控制库存超卖的必要条件,但不是充分必要条件. 举例: 总库存:4个商品 请求人:a.1个商品 b.2个商品 c.3个商品 程序如下: beginTr

高并发的核心技术-幂等的实现方案

一.背景 我们实际系统中有很多操作,是不管做多少次,都应该产生一样的效果或返回一样的结果. 例如: 1. 前端重复提交选中的数据,应该后台只产生对应这个数据的一个反应结果. 2. 我们发起一笔付款请求,应该只扣用户账户一次钱,当遇到网络重发或系统bug重发,也应该只扣一次钱: 3. 发送消息,也应该只发一次,同样的短信发给用户,用户会哭的: 4. 创建业务订单,一次业务请求只能创建一个,创建多个就会出大问题. 等等很多重要的情况,这些逻辑都需要幂等的特性来支持. 二.幂等性概念 幂等(idemp