大庆建设中等职业技术学校网站大同建设银行保安招聘网站

大庆建设中等职业技术学校网站,大同建设银行保安招聘网站,自己建设网站需要什么条件,濮阳网格化app乐观锁和悲观锁详解面试高频 实战常用的并发控制手段 核心问题#xff1a;什么时候锁别人#xff0c;什么时候先干再说#xff1f;一、先把概念捋清楚 1. 悲观锁#xff08;Pessimistic Lock#xff09; 思想#xff1a;“我觉得你一定会和我抢#xff0c;所以我先把门…乐观锁和悲观锁详解面试高频 实战常用的并发控制手段核心问题什么时候锁别人什么时候先干再说一、先把概念捋清楚1. 悲观锁Pessimistic Lock思想“我觉得你一定会和我抢所以我先把门锁上再干活。”假设“冲突很可能发生”在读/写数据前先加锁其他事务读写会被阻塞或受限典型实现数据库的行锁 / 表锁SELECT ... FOR UPDATE等。2. 乐观锁Optimistic Lock思想“我先干活最后再确认一下期间有没有人改过如果有就重来。”假设“冲突很少发生”操作数据时不立即加锁提交前检查是否有冲突冲突检测失败一般是重试或提示失败典型实现版本号version 字段、时间戳、CASCompare And Swap。一句话总结悲观锁先上锁再干活乐观锁先干活最后校验。二、悲观锁详解2.1 悲观锁的典型场景并发写多、冲突概率高更新逻辑复杂且代价大重试成本高强一致性要求高的场景银行转账库存扣减但业务逻辑复杂、流水多步更新余额变动、核心账户系统等。2.2 在数据库层的实现以 MySQL InnoDB 为例常见悲观锁语法-- 排他锁写锁锁住选中的行其他事务不能修改/加排他锁SELECT*FROMproductWHEREid1FORUPDATE;-- 共享锁读锁允许多个事务加共享锁但不能加排他锁SELECT*FROMproductWHEREid1LOCKINSHAREMODE;特点需要在事务中使用BEGIN;SELECTstockFROMproductWHEREid1FORUPDATE;-- 检查库存并更新UPDATEproductSETstockstock-1WHEREid1;COMMIT;InnoDB 会对命中的行加行锁可能伴随间隙锁其他事务如果也想FOR UPDATE同一行会被阻塞直到锁释放或超时。2.3 悲观锁的优点一致性强锁住资源避免同时修改逻辑简单思维模型直接容易理解适合对数据正确性极度敏感的场景。2.4 悲观锁的缺点并发度低大量事务同时抢同一行时会排长队可能出现死锁多个事务交叉持有锁锁等待时间长影响整体性能对长事务极不友好事务持锁时间越长影响越大。三、乐观锁详解3.1 乐观锁的典型场景读多写少冲突相对较少允许“失败重试”的业务不希望加锁阻塞提高并发度用户资料更新配置信息修改大部分后台管理类表单更新一些简单扣减场景如非极端抢购。3.2 版本号实现方式最常用数据表设计CREATETABLEproduct(idBIGINTPRIMARYKEY,nameVARCHAR(50),stockINT,versionINTNOTNULL);业务流程先查出数据SELECTid,stock,versionFROMproductWHEREid1;更新时带上版本条件UPDATEproductSETstockstock-1,versionversion1WHEREid1ANDstock0-- 防止扣成负数ANDversion#{oldVersion};判断执行结果如果UPDATE返回影响行数 1说明版本匹配更新成功如果返回 0说明数据已经被别人修改过version 不相等 / stock 不够当前更新失败需要重查数据后重试或直接报“库存不足”/“数据已更新请刷新”等。**本质**把“加锁串行化”变成“无锁 成功就成功失败就重试/提示”。3.3 其他乐观锁方式时间戳字段通过比较update_time是否等于原值来判断是否被修改。字段值对比不单独用版本号而是直接比较旧值UPDATEuserSETbalancebalance100WHEREid1ANDbalance#{oldBalance};CAS 思想在内存 / Redis 等类似compareAndSet(oldValue, newValue)仅在值没变时才更新。3.4 乐观锁的优点不依赖数据库锁减少阻塞提高吞吐在冲突少的情况下整体性能非常好实现简单在业务层加版本字段 条件更新。3.5 乐观锁的缺点遇到高并发 高冲突的热点数据失败重试次数可能很多业务复杂时重试逻辑难写。并不能完全避免“丢更新”真正安全依赖 SQL 条件如果更新语句写错没带版本条件就失去了保护。四、乐观锁 vs 悲观锁 对比总结4.1 思想层面对比对比维度悲观锁乐观锁冲突假设相信“会冲突”相信“很少冲突”控制方式先加锁再操作不加锁提交时校验版本读写关系写时阻塞其他读/写视锁类型而定读写通常不互相阻塞失败代价一般不会失败除死锁或异常可能更新失败需要重试或提示实现位置多在数据库层行锁、表锁等多在业务/应用层version 字段、CAS 等4.2 使用场景对比场景类型推荐方案银行转账、资金扣减悲观锁 严格事务秒杀、抢购库存通常结合多种手段限流、队列乐观锁只是其中一环一般配置更新、个人信息修改乐观锁复杂多步更新且高度冲突更倾向悲观锁分布式系统跨服务修改多采用乐观锁 重试或分布式锁五、MySQL Java 中的常见用法5.1 MySQL 中的悲观锁-- 案例扣减库存悲观锁版本BEGIN;SELECTstockFROMproductWHEREid1FORUPDATE;-- 检查 stock 1UPDATEproductSETstockstock-1WHEREid1;COMMIT;注意事务必须显式开启FOR UPDATE 会加行锁避免并发修改冲突。5.2 MySQL 中的乐观锁-- 先查SELECTid,stock,versionFROMproductWHEREid1;-- 再更新乐观锁UPDATEproductSETstockstock-1,versionversion1WHEREid1ANDstock0ANDversion#{oldVersion};在业务代码中判断影响行数 1 → 成功影响行数 0 → 失败可能是库存不足或被别人先一步更新。5.3 Java / JPA 中的乐观锁示例例如使用 JPA / HibernateEntitypublicclassProduct{IdprivateLongid;privateIntegerstock;VersionprivateIntegerversion;}添加Version字段后JPA 在更新时会自动加上版本条件WHERE id ? AND version ?如果更新失败会抛出乐观锁异常需要业务做重试或处理。六、如何选择用乐观锁还是悲观锁可以记一个简单判断维度冲突概率高不高高更倾向用悲观锁低乐观锁更合适。能不能接受重试能乐观锁没问题不能比如写操作很重、事务很复杂更适合悲观锁。并发量大小极高并发 单热点纯悲观锁会把大家都锁死纯乐观锁失败率很高也会浪费资源通常要结合限流、队列、拆分热点等手段。一致性要求资金、余额这类强一致场景更多配合悲观锁 / 严格事务一般业务数据乐观锁足够必要时给用户一个“请刷新页面”的提示。七、小结悲观锁特点先上锁再操作牺牲并发换取简单强一致实现SELECT ... FOR UPDATE、行锁、表锁等。乐观锁特点先操作再校验冲突失败就重试或提示实现版本号字段、时间戳、CAS。如何选冲突高 严格一致性 难以重试 → 倾向悲观锁冲突低 允许失败重试 追求高并发 → 倾向乐观锁。真正的生产系统里往往是两种都用某些关键点用悲观锁兜底大部分业务采用乐观锁 幂等 重试机制来换取性能和扩展性。