【java web项目什么场景下需要多线程以及加锁】

2017-01-03 08:54:27 1.5k 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

Java多线程之高级并发编程的应用场景和实践本节介绍了Java高级并发编程的应用场景和实践，包括并发编程的应用场景、使用线程池、锁和同步器、原子变量和CAS、线程安全的数据结构、避免死锁和活锁、使用volatile关键字、并发工具类和合理设计线程安全的程序等实践方法。volatile关键字可以保证变量的可见性，避免线程安全问题和数据不一致的情况。线程安全的数据结构可以避免线程安全问题和数据不一致的情况。合理设计线程安全的程序可以避免线程安全问题和数据不一致的情况。使用原子变量和CAS可以避免线程安全问题和数据不一致的情况。阅读详情

如题，工作多年，其实直接操作多线程的情况还是很少的，因为现在很多Struts2、springmvc等MVC框架已经可以设置为多例的了。这样就没有必要设置加锁了。

有些人可能会反驳说业务层需要加锁，其实这个一般场景是给数据库数据访问加锁的，这个也可以放到数据库中来控制。比如通过版本号之类的。

之前在公司，看我们技术老大些代码控制加锁还是用synchronized，我就呵呵了。。。。
另外有人说做金额方面操作需要加锁之类的，其实这个也是数据范畴了，用数据库版本号也是可以控制的。而且都是多例的了，你控制它有啥鸟用呢？？？？

...全文

springboot高并发细粒度加锁(key粒度加锁) 1、场景：设想，多线程对key=fusor:${order_id}并发访问触发了竞态条件，例如两个线程同时发现key=fusor:${order_id}的值为5，然后并且+1回写6，这个时候就出现了问题，最终的值为6而不是7。 2、粗粒度锁：这时候，普遍的做法是加锁，但是如果对整个访问redis的动作加锁，那么等于多个线程串行访问了！ 3、细粒度加锁：我们这里的做法是对key进行细粒度加锁，每个key拥有一把锁，只对key进行并发控制，key与key之间允许并发。 4、细粒度代码 im 阅读详情

达达KZT

非技术区 23,404 成员 70,506 内容

+ 关注 + 加入社区

切换为时间正序

达达KZT 2017-01-18

打赏
举报

引用 7 楼 aqzwss 的回复:

引用 2 楼 zhou9898 的回复:
[quote=引用 1 楼 aqzwss 的回复:] 如果只是无逻辑的增删改查确实使用现有的成熟框架不需要多线程的知识，但一个对外成熟的应用会涉及到很多很多系统级别功能，这部分逻辑大多需要自己完成多线程开发。
额。。。。能具体嘛

没必要说加锁，涉及到线程安全就是一个意思了。[/quote] 嗯，我目前想咨询的是一般什么业务场景下会需要用到加锁的，请不要抖机灵。。。。。

X元素 2017-01-17

打赏
举报

楼主我倒是觉得synchronized关键字的使用需要看场景，如果场景简单且锁颗粒度控制合理，倒是看着清晰。我给你举个例子说明一下，现在有两个服务A ， B 两服务通过nginx来进行转发且具有相同功能，例如购买某个商品，商品是具有库存的，每次都需要减库存操作，当并发环境下，楼主说的数据库加版本这种方案是不可行的，原因同一时间你的设计只能有且只有一个人购买成功，那用户的体验会很差。

萧乡月夜 2017-01-17

打赏
举报

引用 2 楼 zhou9898 的回复:

引用 1 楼 aqzwss 的回复:
如果只是无逻辑的增删改查确实使用现有的成熟框架不需要多线程的知识，但一个对外成熟的应用会涉及到很多很多系统级别功能，这部分逻辑大多需要自己完成多线程开发。
额。。。。能具体嘛

没必要说加锁，涉及到线程安全就是一个意思了。

萧乡月夜 2017-01-17

打赏
举报

引用 4 楼 zhou9898 的回复:

[quote=引用 3 楼 u011619071 的回复:] 楼主我倒是觉得synchronized关键字的使用需要看场景，如果场景简单且锁颗粒度控制合理，倒是看着清晰。我给你举个例子说明一下，现在有两个服务A ， B 两服务通过nginx来进行转发且具有相同功能，例如购买某个商品，商品是具有库存的，每次都需要减库存操作，当并发环境下，楼主说的数据库加版本这种方案是不可行的，原因同一时间你的设计只能有且只有一个人购买成功，那用户的体验会很差。

你说的这个场景并发稍微高点，用synchronized你会怀疑人生的。。。。好了，这个咱们不讨论这个的，我主要是想问问什么场景需要用到加锁，至于什么方式，都没啥所谓啦。另外一般的RPC调用还要走nginx？[/quote] 其实synchronized必将是未来加锁的最终实现方式，jdk的开发每次版本都会优化synchronized实现，最典型的是1.5-1.6，性能提升了*N，只是现在还没有找到一个足够智能的形式来代替cas等逻辑模式。

达达KZT 2017-01-17

打赏
举报

引用 1 楼 aqzwss 的回复:

如果只是无逻辑的增删改查确实使用现有的成熟框架不需要多线程的知识，但一个对外成熟的应用会涉及到很多很多系统级别功能，这部分逻辑大多需要自己完成多线程开发。

额。。。。能具体嘛

X元素 2017-01-17

打赏
举报

引用 4 楼 zhou9898 的回复:

[quote=引用 3 楼 u011619071 的回复:] 楼主我倒是觉得synchronized关键字的使用需要看场景，如果场景简单且锁颗粒度控制合理，倒是看着清晰。我给你举个例子说明一下，现在有两个服务A ， B 两服务通过nginx来进行转发且具有相同功能，例如购买某个商品，商品是具有库存的，每次都需要减库存操作，当并发环境下，楼主说的数据库加版本这种方案是不可行的，原因同一时间你的设计只能有且只有一个人购买成功，那用户的体验会很差。

你说的这个场景并发稍微高点，用synchronized你会怀疑人生的。。。。好了，这个咱们不讨论这个的，我主要是想问问什么场景需要用到加锁，至于什么方式，都没啥所谓啦。另外一般的RPC调用还要走nginx？[/quote] 假设我的A 跟B 都是provider ，而且具有同一个接口实现，卖商品减库存，这样楼主应该明白我的意思了，另外一点我说的业务场景，synchronized是解决不了的，只是说明synchronized关键字的使用也是分情况的，lock有lock的优势。 synchronized有synchronized的好处，楼主觉得呢？

达达KZT 2017-01-17

打赏
举报

引用 3 楼 u011619071 的回复:

楼主我倒是觉得synchronized关键字的使用需要看场景，如果场景简单且锁颗粒度控制合理，倒是看着清晰。我给你举个例子说明一下，现在有两个服务A ， B 两服务通过nginx来进行转发且具有相同功能，例如购买某个商品，商品是具有库存的，每次都需要减库存操作，当并发环境下，楼主说的数据库加版本这种方案是不可行的，原因同一时间你的设计只能有且只有一个人购买成功，那用户的体验会很差。

你说的这个场景并发稍微高点，用synchronized你会怀疑人生的。。。。好了，这个咱们不讨论这个的，我主要是想问问什么场景需要用到加锁，至于什么方式，都没啥所谓啦。另外一般的RPC调用还要走nginx？

萧乡月夜 2017-01-16

打赏
举报

如果只是无逻辑的增删改查确实使用现有的成熟框架不需要多线程的知识，但一个对外成熟的应用会涉及到很多很多系统级别功能，这部分逻辑大多需要自己完成多线程开发。

【java web项目什么场景下需要多线程以及加锁】

相关推荐