我看网上好多都是有了事务管理,却还用同步锁保证并发不出错。事务使用数据库自带的锁,可以锁住表,避免出现不可重复读、脏读和幻读。对于存在于事务中的

//获取用户select
//删除用户

为什么还要用synchronied保证不会删除不存在的用户呢呢?

解决方案 »

  1.   


    这样理解。 synchronied是保证上面的操作原子性,因为上面有两个操作 一个是select动作,还有一个是delete动作。现假设有两个线程执行这一段代码,且执行的时间窗口有重叠 。线程一和同时执行了select 语句,都获得了用户了,然后线程一发送“删除用户”给令给数据库,然后线程二也发送“删除用户”给令给数据库。即两个线程同时执行select操作,但执行删除操作的时候 一前一后 就会出现 删除不存在的用户 。因为线程一 已经删除了用户 但是线程二却不知道。 加synchronied后,两个线程执行这一段代码没有任何时间重叠,两个组合操作变成了一个原子操作
      

  2.   


    这样理解。 synchronied是保证上面的操作原子性,因为上面有两个操作 一个是select动作,还有一个是delete动作。现假设有两个线程执行这一段代码,且执行的时间窗口有重叠 。线程一和同时执行了select 语句,都获得了用户了,然后线程一发送“删除用户”给令给数据库,然后线程二也发送“删除用户”给令给数据库。即两个线程同时执行select操作,但执行删除操作的时候 一前一后 就会出现 删除不存在的用户 。因为线程一 已经删除了用户 但是线程二却不知道。 加synchronied后,两个线程执行这一段代码没有任何时间重叠,两个组合操作变成了一个原子操作
      

  3.   

    现假设数据库的事务默认隔离级别是读取已提交的数据现假设当在事务中执行select动作的时候,有另外一个线程在事务中执行插入动作且插入的数据已经提交给数据库 则数据库会保证select动作一定会读取到刚刚插入的数据,这就是事务。
      

  4.   

    如果部署多个节点,synchronied其实是没多大意义的。 
    可以使用乐观锁。
      

  5.   

    在事务的锁的级别很高的情况下,其实是不需要再用synchronied的;有时为了减轻数据库压力,放宽事务的锁,把压力放在应用服务器上,也就使用了同步锁
      

  6.   


    这样理解。 synchronied是保证上面的操作原子性,因为上面有两个操作 一个是select动作,还有一个是delete动作。现假设有两个线程执行这一段代码,且执行的时间窗口有重叠 。线程一和同时执行了select 语句,都获得了用户了,然后线程一发送“删除用户”给令给数据库,然后线程二也发送“删除用户”给令给数据库。即两个线程同时执行select操作,但执行删除操作的时候 一前一后 就会出现 删除不存在的用户 。因为线程一 已经删除了用户 但是线程二却不知道。 加synchronied后,两个线程执行这一段代码没有任何时间重叠,两个组合操作变成了一个原子操作
    当事务的隔离级别是seriazeble的时候不是杜绝了这种虚读的情况了吗,您的举例不太好吧。
      

  7.   

    事务不能保证并发,事务只是保证一次提交多个sql要么都成功要么都失败,事务的本质也是调用数据库的排它锁和共享锁。要保证一个事务中只有一个线程,就需要java同步锁。
      

  8.   

    事务有级别,有的仅仅是锁住了一条数据而已,如果都锁住整张表的话,系统效率会降低
    有的时候并不需要在那么大范围内加锁
    所以改用syn关键字,灵活的控制锁的范围
      

  9.   

    事务是保证多个sql或者跨多个数据库操作,能原子操作。而锁是控制代码层面防止多个并发造成数据不一致性。