5
回答
java多线程-线程安全性疑问
终于搞明白,存储TCO原来是这样算的>>>   

比如我们有个User对象    有个count属性

1.然后我要执行++操作!我再想synchronized 还是解决不了问题吧!除非synchronized整个对象

2.加锁:看很多的用法都是在一个方法中加锁/解锁

Lock lock = new ReentrantLock();
...
lock.lock();//显示加锁
try{
    ...
}finally{
    //显示释放锁
    lock.unlock();
}



但是,我很多线程在取得user对象后  延迟点时间  然后再setCount(getCount()+1);
不一样出现数据问题了么?

难道我取出来的时候加锁,然后比我update后再解锁!总是感觉怪怪的!

或者有没有多线程/并发 讲得比较接地气的书推荐推荐呢

举报
SandKing
发帖于3年前 5回/291阅

以下是问题补充:

  • @SandKing :我想的是在数据层控制数据的安全,而不想把锁加到逻辑层去 (3年前)
共有5个答案 最后回答: 3年前
没看懂你的问题,到底是java里面还是数据库里面,如果是java里面,就用AtomicInteger、AtomicLong之类的就可以了, 用getAndIncrement 方法,有其它需要的话还有getAndSet、getAndAdd之类的。

引用来自“Maxwell1987”的评论

没看懂你的问题,到底是java里面还是数据库里面,如果是java里面,就用AtomicInteger、AtomicLong之类的就可以了, 用getAndIncrement 方法,有其它需要的话还有getAndSet、getAndAdd之类的。
楼主,这个答案应该可以解决你的问题。
--- 共有 12 条评论 ---
SandKing回复 @Maxwell1987 : 你做成 change 的api 是 修改缓存中数据吧!我之所以每个查询要copy一个数据副本出来!是我可能会做回滚操作!只有调用了 update 类似的 提交数据修改操作才会真实的去修改数据.copy一个数据副本出来 你做change api也就没什么意义了 3年前 回复
Maxwell1987回复 @SandKing : 哪个方面的安全,思路都是这样的。而且也不会显著比在底层处理复杂,更何况在底层处理不是个正确的方法。 3年前 回复
SandKing回复 @Maxwell1987 : 我要的不仅仅是数值的变动安全 3年前 回复
Maxwell1987回复 @SandKing : 把同步放到业务api里,不要放到使用业务api的代码里。 3年前 回复
Maxwell1987回复 @SandKing : 在业务层的资源增减接口里面,做同步就可以了啊,有什么不好处理的 3年前 回复

volatile int count 读不用加锁,所有的写加锁。有race condition的也加锁。

如果只是++,--,没有race condition的,直接用AtomicInteger, 不用自己维护锁

--- 共有 4 条评论 ---
purely回复 @SandKing : 在没有race condition的条件下,读取数据不一致时正常的。现在有个count=1,你8个线程读到8,然后被改成了count=2,然后剩下2个线程读到2,这中是正常的。不过有一点我忘了说了,也就是写的时候,必须是原子写(想double这种不是原子写的,是不能不加锁读的),参考currenthashmap的代码,采用的是final+volatile,实现不加锁读 3年前 回复
lock_free回复 @SandKing : 有专门的读写锁 3年前 回复
SandKing还有读不加锁 我多个线程并发的时候 比如10个 拿到的数据副本是一样的,但我写的时候加锁?到底10个线程中。最后是那一个执行。其中就有9个线程处理的数据丢了!!! 3年前 回复
SandKing如果只考虑++ -- 我也不用费这么大的劲了!我不但要考虑数值,字符串也要完全正确 3年前 回复
顶部