首页 > 试题广场 >

请你说说乐观锁和悲观锁

[问答题]
请你说说乐观锁和悲观锁
乐观锁:乐观锁总是假设最好的情况,每次去拿数据的时候默认别人不会修改,所以不会上锁,只有当更新的时候会判断一下在此期间有没有人更新了这个数据。适用于多读,可以使用版本号机制进行控制 悲观锁:悲观锁总是假设最坏的情况,每次去拿数据是都认为别人会修改,所以每次在拿数据时都会上锁,这样别人想拿这个数据时会阻塞直到拿到锁。mysql数据库的共享锁和排他锁都是悲观锁的实现。
发表于 2022-04-20 15:55:04 回复(0)
乐观锁:线程在对数据进行修改时,会先核验版本号是否一致,一致则修改,不一致则不进行修改。悲观锁:线程在对数据进行修改时,其他线程无法进入。
发表于 2022-05-02 16:18:33 回复(0)
乐观锁就是根据版本号来校验,更新操作时会带上版本号;悲观锁就是在操作的时候给数据上锁,自己操作的时候别人就不能操作;
发表于 2022-05-03 14:53:01 回复(0)
乐观锁:乐观锁总是假设最好的情况,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型;悲观锁:悲观锁总是假设最坏的情况,每次去拿数据的时候都认为别人会修改,所以每次在拿数据就会阻塞直到它拿到锁(共享资源每次只给一个线程使用,其它线程阻塞,用完后再把资源转让给其它线程)传统的关系型数据库就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等都是在做操作之前线上锁
发表于 2022-05-06 18:31:54 回复(1)
悲观锁就是认为所有操作都是不可靠的,乐观锁认为所有操作应该是可靠的。。悲观锁直接通过加锁实现,,乐观锁可以通过进行version对比
发表于 2022-05-04 21:00:37 回复(0)
乐观锁,顾名思义什么都想的特别乐观,每次拿数据时默认别人不会修改,认为所有操作应该是可靠的,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号机制和CAS算法实现。 悲观锁,就是什么都想的特别悲观,每次拿数据时默认别人会修改,因为会加上锁,别人想拿这个数据就会阻塞。
发表于 2022-08-15 14:26:50 回复(0)
这两个索引是关于数据跟索引的分离,聚簇索引不分离,非聚簇索引分离
编辑于 2022-08-15 18:31:53 回复(1)
乐观锁假设其他人拿到数据后不会做修改,所以允许数据被多人同时读取,在修改完成后提交时会判断在修改期间数据是否有过变化(其他人是否做过修改),乐观锁可以用版本机制(每次提交修改时判断版本是否和数据库中的版本一致)或CAS算法实现(判断预期内容是否和实际内容相符),乐观锁适用的场景比如在Gitee中多人协同合作完成一个项目,一个内容在同一时间可以被多人读取可以很大程度上提高开发效率;悲观锁假设数据被读取后就会做修改,所以一次只允许一个人读取数据,其他人会被阻拦直到读取数据的人操作完成,相当于资源一次只给到一个线程,其他线程会被阻塞直到资源被释放出来,悲观锁的适用场景是并发量不太大(并发量太大而每次只有一个线程能使用资源会导致系统性能下降)或者发生并发会导致程序异常等情况。
发表于 2022-06-16 17:29:49 回复(0)
乐观锁:\·_·/ 悲观锁:/·︵·\
发表于 2022-06-15 23:00:03 回复(1)
乐观锁总是假设最好的情况,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间是否有别人更新了这条数据。也就是先查询出那条记录,获取出version字段,如果要对那条记录进行操作(更新),则先判断此刻数据库中的version的值是否与刚刚查询出来时的version的值相等,如果相等,则说明这段期间,没有其他人对其进行操作,则可以执行更新,将version字段的值加1;如果更新时发现此刻的version值与刚刚获取出来的version的值不相等,则说明这段期间已经有其他人对其进行操作了,则不进行更新操作,从而确保数据的一致性。乐观锁一般会使用版本号机制或 CAS 算法实现。悲观锁就是每次去拿数据时都会上锁,其他人会被阻塞住,直到当前操作释放锁,比如行锁,表锁等,读锁,写锁等,都使用了该锁。
编辑于 2023-04-04 16:17:29 回复(0)
乐观锁指的是多个线程可以同时操作一个资源,最后由每个线程各自判断,这个资源是否被其他线程给修改了,如果修改了,那么就放弃本次操作,没有修改的话,自己可以做更新,然而其他线程就不能更新了,可以使用CAS机制或者版本号来控制,不会阻塞其他线程。适合读多的场景 悲观锁指的是多线程下,只能有一个线程去执行,其他线程只能阻塞等待,像synchronized、lock锁,适合写多的场景
发表于 2022-12-19 19:21:31 回复(0)
乐观锁:总是假设最好的情况,每次拿数据时默认别人不会修改,所以不会上锁,在执行更新操作时会判断在此期间有没有人更新数据。悲观锁:总是假设最坏的情况,每次拿数据都认为别人会修改,在拿数据时都会上锁,别人想拿数据时会进入阻塞状态
发表于 2022-11-08 15:39:22 回复(0)
乐观锁就是假设都是最好的情况,每次那数据都没有人在修改,使用不会上锁,只会判断一是否有人修改过。使用于多读。可以加版本号。悲观锁就是假设都是最坏的情况每次去拿数据都有人修改,使用每次拿数据都会上锁,这样别人想那这个数据就会阻塞,直到数据修改完成。mysql数据库的共享锁和排他锁都是悲观锁的实现
发表于 2022-09-17 19:53:19 回复(0)
这个版本控制的举例一下子恍然大悟。
发表于 2022-08-29 09:50:08 回复(0)
乐观锁:总是假设最好的情况,就是再程序执行的过程中全程不上锁,只有在最后提交的时候才检查数据是否相等。可以使用版本号和CAS算法实现。 悲观锁:总是假设最坏的情况,每次拿数据的时候都认为被人会修改,所以在每次拿数据的时候都会上锁,这样被人在拿这个数据的时候就会阻塞,直到它拿到锁。
发表于 2022-05-06 14:50:58 回复(0)
乐观锁:总是假设是最好的情况,认为别人不会修改,不会上锁但是要进行修改数据上,会检查别人有没有更新数据,可以使用版本号机制和CAS算法,适用于多读情况,可提高吞吐量 悲观锁:总是假设最坏的情况,每次不管是读还是写,都会进行上锁, 适用于并发量不是很大的情况下使用
编辑于 2024-03-17 20:41:05 回复(0)
处理多个线程同时访问共享资源时可能出现的数据竞争和并发访问问题。悲观锁的核心思想是认为并发访问的情况下会出现数据冲突,因此在访问共享资源时先进行加锁,确保同一时刻只有一个线程可以访问共享资源,其他线程需要等待锁的释放。乐观锁的核心思想是认为并发访问的情况下不会出现数据冲突,因此在访问共享资源时不立即加锁,而是先进行读取和操作,然后在更新数据时检查是否被其他线程修改过,如果没有则进行更新,否则进行回滚或重试操作。
发表于 2024-02-26 10:22:56 回复(0)
乐观锁总是假设最好的情况,每次去拿数据的时候默认别人不会修改,所以不会上锁,只有当更新的时候回判断在此期间有没有人更新了这个数据。适用于多读,可以使用版本号进行控制。 悲观锁总是假设最坏的情况,每次拿数据都认为别人修改了,所以每次拿数据都上锁,mysql的共享锁和排他锁都是悲观锁。
发表于 2024-02-22 09:40:56 回复(0)
乐观锁,默认一切正常;悲观锁,默认加锁
编辑于 2024-02-06 10:05:06 回复(0)
乐观锁会假设每次使用数据都不会修改,悲观锁相反。
发表于 2023-12-11 12:00:08 回复(0)