- 综合排序
- 最热优先
- 最新优先
- 来自专栏用户5325874的专栏
RocketMQ分析——高并发读写
RocketMQ高并发读写 Rocket的高并发读写的原因可以从3个方面进行分析： 生产者负载均衡 生产者发送消息有负载均衡。 Broker 服务端的高并发读写主要利用Linux操作系统的PageCache特性，通过顺序写盘(Commit Log)，跳跃读 来尽量命中PageCahe，从而大大减少磁盘IO。 再加上MQ默认是累计4K才强制从PageCache中刷到磁盘，所以高并发写性能突出。 所以Broker的机器需要大内存，尽量缓存足够多的commitLog，让Broker读写消息基本在PageCache中操作。
3K40发布于 2020-04-16 - 来自专栏全栈程序员必看
Java高并发读写文件
最近在项目中我们遇到了高并发的事情，我是这样操作的。利用JavaNIO实现非阻塞式的读写，通过锁机制完成高并发下的文件的操作。 rw"); long filelength = fout.length();//获取文件的长度 fout.seek(filelength);//将文件的读写指针定位到文件的末尾 } } 上面的代码实现了在文件的末尾追加内容，要想在文件的中间插入内容，这个方法还不能实现，必须读出来，当读到添加内容的位置，添加到StringBuffer中，然后读完文件，将文件读写指针定位开始
2.1K31编辑于 2022-08-30 - 来自专栏Linyb极客之路
并发编程之读写锁
一、读写锁 ReadWriteLock 读写锁维护了一对相关的锁，一个用于只读操作，一个用于写入操作。只要没有writer，读取锁可以由多个reader线程同时保持。写入锁是独占的。 互斥锁一次只允许一个线程访问共享数据，哪怕进行的是只读操作；读写锁允许对共享数据进行更高级别的并发访问：对于写操作，一次只有一个线程（write线程）可以修改共享数据，对于读操作，允许任意数量的线程同时进行读取 与互斥锁相比，使用读写锁能否提升性能则取决于读写操作期间读取数据相对于修改数据的频率，以及数据的争用——即在同一时间试图对该数据执行读取或写入操作的线程数。 读写锁适用于读多写少的情况。 四、ReentrantReadWriteLock应用场景 ReentrantReadWriteLock读写锁：(针对不同操作可以提供不同读或写锁 --读写锁、写写锁之间互斥。 读读锁共享) 写锁和其它任何锁互斥，读锁可以和其它读锁共用，读写锁一般可用于缓存设计
1.9K50发布于 2018-03-27 - 来自专栏晏霖
Java并发之-读写锁ReentrantReadWriteLock
读写锁维护了一对锁，一个读锁和一个写锁，通过分离读写锁，使得并发性相比一般的排他锁有很大提升。 参考文献 《Java并发编程的艺术》 正文 读写锁只需要在读操作时获取读锁，写操作获取写锁即可。 当写操作被获取时，后续读写锁都会被阻塞，写操作释放以后，所有操作继续执行。 一般情况下，读写锁的性能比排他锁要好，因为大多数场景读是多于写的，所以在读多余写时，读写锁能够提供比排他锁更好的性能和吞吐量。java中读写锁实现是 ReentrantReadWriteLock。 ，读写状态就是同步器的同步状态。 如果当前线程在获取写锁时，读写已经被获取，或者该线程不是获取写锁的线程，则当前线程进入阻塞。
63330发布于 2019-06-26 - 来自专栏悠扬前奏的博客
Java并发-17.读写锁
读写锁维护一对锁，读锁和写锁 分离读锁和写锁，并发性比排它锁有很大提升 ReadWriteLock仅定义读锁和写锁的两个方法——readLock()和writeLock() 实现类ReentrantReadWriteLock 保存当前线程获取的次数，这也使得Java 6 的实现变得更加复杂 boolean isWriteLocked() 判断写锁是否被获取 int getWriteHoldCount() 返回当前写锁被获取的次数 读写锁状态的设计
59020发布于 2019-05-28 - 来自专栏半旧的技术栈
juc并发编程05——读写锁
读写锁是针对读、写场景设计的，允许多个线程同时持有锁。读写锁维护了一个读锁和一个写锁。其机制如下： 没有其它线程占用写锁的情况下，同一时间可以有多个线程加读锁。 先回顾下我们对读写锁机制的描述： 没有其它线程占用写锁的情况下，同一时间可以有多个线程加读锁。 发现没有，我们用的是其它，而不是任意。
31630编辑于 2022-10-26 - 来自专栏凯哥Java
Java多线程并发之读写锁
Java多线程并发之读写锁 本文主要内容：读写锁的理论；通过生活中例子来理解读写锁；读写锁的代码演示；读写锁总结。通过理论(总结)-例子-代码-然后再次总结，这四个步骤来让大家对读写锁的深刻理解。 本篇是《凯哥(凯哥Java:kagejava)并发编程学习》系列之《Lock系列》教程的第七篇：《Java并发包下锁学习第七篇：读写锁》。 一：读写锁的理论 什么是读写锁？ 读写锁实际维护了一对锁，一个读锁，一个写锁，通过分离读锁和写锁，使得其并发性比独占式锁(排他锁)有了很大的提升。 为什么需要读写锁？ 这个操作在并发角度来说：千千万万的玩家是读共享资源的；游戏维护者是写操作的。当停服更新的时候，读操作就被阻塞了，只能等写操作，也就是更新完成后，才可以接着玩。 其内部维护了一对锁：一个读锁(ReadLock对象)，一个写锁(writeLock对象)，通过读写分离的方式来提高并发性能。读写锁也叫共享锁。其共享是在读数据的时候，可以让多个线程同时进行读操作的。
1.7K50发布于 2020-04-07 - 来自专栏Java编程技术
Go并发编程之美-读写锁
本节我们先来看看go中读写锁 二、读写锁 go中读写锁，在没有线程获取写锁情况下多个线程可以同时获取读锁，读锁是可重入锁，写锁则是互斥锁（不可重入）。 time" ) var ( counter int //计数器 wg sync.WaitGroup //信号量 lock sync.RWMutex //读写锁 2.3.释放独占锁 lock.Unlock() fmt.Println("sub thread relese rlock") } 如上代码go中使用sync.RWMutex可以获取一个开箱即用的读写锁 () lock.Lock() fmt.Println(counter) lock.Unlock() lock.RUnlock() 上面代码执行会报错： [image.png] 三、总结 go中读写锁中的读锁是可重入共享锁
74620发布于 2019-02-15 - 来自专栏小李的文章专栏
Golang map 并发读写问题源码分析
key进行并发操作就行，但是现实很骨感。 测试时并发量很小的时候可能不会存在问题（只是运气好），并发量一大就会有问题。 但是不是所有场景下并发使用map都是不安全的这是golang的官方文档，上面提到了只要有更新的操作存在，map就是非线程安全的，但是如果使用场景只是并发读，不涉及到写/删操作，那么就是并发安全的。 图片源码分析定义map head中flags字段，记录了当前map的一些状态，其中hashWriting就是造成并发读写map报错的“罪魁祸首”。 = 0 {throw("concurrent map read and map write")}...}结论1.看过源码之后，发现这很像一个读写锁，但是并不会造成任何阻塞，有问题直接throw。
1.7K41编辑于 2022-06-27 - 来自专栏陶士涵的菜地
mysql 的读写锁与并发控制
1.无论何时只要有多个查询在同一时刻修改数据,都会产生并发控制的问题 2.讨论mysql在两个层面,服务器层和存储引擎层,如何并发控制读写 3.举了个mbox邮箱文件的例子,说如果有多个进程同时对mbox 那么在文件的末尾会,交叉混乱的添加,比如进程1写了几行,进程2也写了几行,互相交叉,数据就是错误的了.设计良好的mbox需要加锁,比如进程1锁住了文件,进程2必须等待进程1结束,锁释放才能去写.但是这样的话就不支持并发了 读取时可能也会有问题,比如一个进程正在读数据,另一个进程同时想去删数据,此时就是不安全的;共享锁叫读锁,排他锁叫写锁 5.读锁是共享的,它不会阻塞其他读锁;写锁是排他的,它会阻塞其他读锁和写锁;读读不互斥,读写互斥 ,那几行其他用户不能读和写;其他行没有影响,但是管理锁会消耗资源,innodb 8.使用命令来锁表 unlock tables 解锁所有行 lock tables 表名 read或者write 测试读写
1.3K30发布于 2019-09-10 - 来自专栏陈树义
Java并发编程：同步锁、读写锁
从结果可以看出，线程0获取到锁并不会阻塞线程1获取锁，因此可以知道读锁其实是并发的。 三、一个读写锁的例子 读写锁与一般的锁的不同之处就是它有两种锁，分别是读锁（ReadLock）和写锁（WriteLock）。当我们锁上读锁的时候，其他线程也可以读取对象的数据，但是不能修改。 这样就即保证了读取数据的高并发，又保证了线程的数据安全。 com.chanshuyi.class12; import java.util.Random; import java.util.concurrent.locks.ReentrantReadWriteLock; /** * 读写锁实现读写互斥又不影响并发读取 也就是保证了程序读取的并发性能，又保证了线程的数据安全。
1.4K70发布于 2018-04-13 - 来自专栏专注 Java 基础分享
并发显式锁之读写锁
因而在某些读操作远大于写操作的场景之下，即便我只是读数据也不得不排队一个一个来，于是有人提出了一个『读写锁』的概念。 『读写锁』并不是真正意义上的读写分离，它只允许读读共存，而读写、写写依然是互斥的，所以只有在大量读操作、少量甚至没有写操作的情境之下，读写锁才具有较高的性能体现。 如果是由于临界资源正在被写锁锁住，那么认为你不应该再尝试了，先去阻塞等着吧，而如果是由于并发修改 state 导致的失败，那么将进入循环尝试，直到成功或是遇到和上述一样的情况，有写锁成功的占有了临界资源 否则，如果有写线程正在工作并且不是自己，那么直接返回失败，不再尝试，否则就是自己重入了该临界资源了，直接无并发增加持有次数。 所以，读写锁的复杂点在于读锁的共存，写锁是互斥的，没有过多的要求，重点在于对读锁的理解。 关注公众不迷路，一个爱分享的程序员。
55720发布于 2019-05-25 - 来自专栏Java编程技术
Go并发编程之美-读写锁
本节我们先来看看go中读写锁 二、读写锁 go中读写锁，在没有线程获取写锁情况下多个线程可以同时获取读锁，读锁是可重入锁，写锁则是互斥锁（不可重入）。 var ( counter int //计数器 wg sync.WaitGroup //信号量 lock sync.RWMutex //读写锁 释放独占锁 lock.Unlock() fmt.Println("sub thread relese rlock") } 如上代码go中使用sync.RWMutex可以获取一个开箱即用的读写锁 image.png 三、总结 go中读写锁中的读锁是可重入共享锁，写锁是互斥锁，读锁不能晋升为写锁。
45920发布于 2019-03-04 - 来自专栏核心思路逻辑
mongo集群中读写操作与并发
secondaryPreferred upsert是否为原子操作 mongo的upsert命令【不是】原子的,upsert 分为两步: 找数据 覆盖数据或插入数据 在使用该功能时,需考虑fifter条件是否作唯一, 在并发下 collection.createIndex($unique_keys, { backgroud : true, unique : true}),如果不加【unique : true】则为普通索引,解决不了并发重复的问题 事务问题 事务中读操作 mongo在指定读写分离时,即 readPreference=secondaryPreferred或者readPreference=secondary时, 在代码中开启事务时,
34710编辑于 2024-11-27 - 来自专栏专注 Java 基础分享
并发显式锁之读写锁
因而在某些读操作远大于写操作的场景之下，即便我只是读数据也不得不排队一个一个来，于是有人提出了一个『读写锁』的概念。 『读写锁』并不是真正意义上的读写分离，它只允许读读共存，而读写、写写依然是互斥的，所以只有在大量读操作、少量甚至没有写操作的情境之下，读写锁才具有较高的性能体现。 如果是由于临界资源正在被写锁锁住，那么认为你不应该再尝试了，先去阻塞等着吧，而如果是由于并发修改 state 导致的失败，那么将进入循环尝试，直到成功或是遇到和上述一样的情况，有写锁成功的占有了临界资源 否则，如果有写线程正在工作并且不是自己，那么直接返回失败，不再尝试，否则就是自己重入了该临界资源了，直接无并发增加持有次数。 所以，读写锁的复杂点在于读锁的共存，写锁是互斥的，没有过多的要求，重点在于对读锁的理解。
关注公众不迷路，一个爱分享的程序员。 52140发布于 2019-02-14 - 来自专栏皮皮星球
golang map的并发读写导致panic
前言 golang在官方的 FAQ 提到过map不是线程安全的，如果有并发场景需要自己加锁，或者使用sync包里的Map。 这本是众所周知的问题，但是本文的重点是记录一个压测过程中进程panic问题，panic的报错信息是map的并发读写和并发写的情况，但是一波分析之后，原因并不出在map上，而是一个slice的操作问题。 那么这时候并发append就会有 DATA RACE 的情况发生。 ，程序panic，报错日志中其他panic是map的并发读写，根因必然也是如此了。 回顾整个过程，golang的map并发读写造成的原因可能有很多，但是并发问题一定是有变量被共享了，多个协程一起操作，只要基于这个原则，顺着堆栈，根据代码找到泄漏的地方就可以。
6.4K10发布于 2020-09-23 - 来自专栏写两行代码放松下
modernc.orgsqlite驱动SQLite并发读写研究
背景针对Go语言modernc.org/sqlite驱动并发读写过程中的报错“database is locked (5) (SQLITE_BUSY)”的研究。 time.Since(startT)fmt.Printf("time cost:%s\n", tc.String())}结论journal_mode = wal 和 busy_timeout = 10000 无法保证并发读写不报错 ；读写锁无法保证并发读写不报错（包括并发读）；所有SQL操作都用写锁，能保证并发读写不报错。
1.8K70编辑于 2023-07-17 - 来自专栏同步文章
【并发编程】可重入锁和读写锁
结果分析： 线程1 2 4 对应一个Condition 线程4唤醒线程1和2 线程3 5 对应另一个Condition 线程5唤醒线程3 ReentrantReadWriteLock 读写锁 读写锁ReentrantReadWriteLock 核心是实现读写分离的锁 在高并发访问下 尤其是读多写少 性能远高于重入锁 本质是分成两个锁 读锁和写锁 在读锁下 多个线程可以并发的进行访问 但在写锁的时候 只能一个个的顺序访问 读读共享 写写互斥 读写互斥 上代码： import java.util.concurrent.locks.ReentrantReadWriteLock; import java.util.concurrent.locks.ReentrantReadWriteLock.ReadLock
48840编辑于 2022-10-25 - 来自专栏博客专享
并发设计模式实战系列(6)：读写锁
今天为大家带来的是并发设计模式实战系列，第六章读写锁模式，废话不多说直接开始~ 一、核心原理深度拆解 1. 读写锁三维模型 2. throws InterruptedException { ReadWriteLockDemo demo = new ReadWriteLockDemo(); // 模拟并发读写 不同锁机制对比 锁类型 并发度 适用场景 死锁风险 synchronized 低 简单同步场景 有 ReentrantLock 中 需要条件变量的场景 有 ReadWriteLock 高 读多写少场景 读写锁实现对比 实现类 特性 适用场景 ReentrantReadWriteLock 支持公平/非公平模式、可重入 通用场景 StampedLock 支持乐观读、锁降级优化 超高并发读取 CopyOnWriteArrayList
26410编辑于 2025-05-20 - 来自专栏深蓝居
shardingdb：支持分片和并发读写的 GoLevelDB
概述 shardingdb 是一个开源包，旨在为 GoLevelDB 增加分片和并发读写功能。它可以作为 LevelDB 的替代品，方便地集成到现有项目中。 - 并发读写：shardingdb 支持并发读写，进一步提高性能。 - 替代品：shardingdb 可以作为 LevelDB 的替代品使用，对现有代码的更改最小。 总结 如果您使用goleveldb，但是又苦于数据量太大，读写性能下降，那么shardingdb 是一个功能强大且易于使用的解决方案，可为 LevelDB 增加分片和并发读写功能。
42631编辑于 2023-09-17
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号