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

[程序员一灯]

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

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

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

[萧乡月夜]

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

[程序员一灯]

引用 3 楼 u011619071 的回复:

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

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

[X元素]

引用 4 楼 zhou9898 的回复:

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

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

[程序员一灯]

引用 1 楼 aqzwss 的回复:

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

额。。。。能具体嘛

[萧乡月夜]

引用 4 楼 zhou9898 的回复:

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

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

[萧乡月夜]

引用 2 楼 zhou9898 的回复:

引用 1 楼 aqzwss 的回复:

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

额。。。。能具体嘛

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

[X元素]

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

[程序员一灯]

引用 7 楼 aqzwss 的回复:

引用 2 楼 zhou9898 的回复:

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

额。。。。能具体嘛

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