其实都不懂,啊多么痛的领悟----关于多线程的若干疑惑

Question

类似下面一段伪代码，对账户更新进行同步，使用第一种方式，感觉锁定是一个毫无意义的对象期，而第二种方式，锁定账户余额，但它是一个随时不断变化的，感觉很不科学？加锁的目标是对象，和对象变不变无关一个类实现Runnable接口，必须也只能实现一个run(),如果有多个业务逻辑需要多线程环境下运行,那只能拆分到多个类,分别实现Runnable接口?是否需要多个Runnable取决于你业务的需求，如果你的业务里的步骤需要异步的并发，那么你是需要多个Runnable。但是我估计你想要的只是一个业务同时被调用，这种情况你不需要多个Runnable接口，只需要多个线程问题3：synchronized同步的效率问题
偏向锁，轻量级锁？Concurrent？网上找了许多资料，越看越糊涂。所以引申出来第3个让我感到脸红的问题。
绝大部分的性能问题都不会是因为synchronized的效率问题引起的，反而，不正确的算法、加锁顺序、加锁策略，甚至数据库，网络等等才是性能问题的元凶，请不要在出了问题之后草率的下定论，去比较synchronized和重入锁哪个效率高，那是很初级的表现问题4：到底在什么情况下使用多线程？我不知道这个问题在是不是好笑，有人可能会说，这算啥问题，在并发量高，等待时间长，消耗资源大的时候就可以使用多线程。但是一些大型电商网站，查询并发也很高，在不考虑服务器压力的情况下（反正站在说话腰不疼的，嘿嘿），为什么不使用多线程而用缓存，貌似多线程肯定只是在对数据库更新操作的情况下使用。我大约只是在有数据需要同步的时候，才会思考需不需要用多线程，这算不算本末倒置。如果仅仅只是需要数据同步的话，那么直接只用户synchronized有无作用？如下：
在存在有非CPU密集型阻塞的时候多线程可以大大的提高效率。因为多线程实际上消耗的是CPU的资源，有些操作例如网络、磁盘IO会阻塞住线程，这时CPU是空转的，效率被浪费了，所以才出现多线程的模型，就是要利用单线程阻塞期间CPU的工作时间。如果你的业务是CPU密集型，就不要上多线程了，线程间的切换会让你的性能雪上加霜。
电商网站的缓存和多线程完全不是一回事，解决的不是同一个问题。另外，java的web容器全部都是多线程的，只不过封装起来了你看不到，平时从来没有关注过，好像就是在写单线程一样。代码什么的不想看了太长了

Answer 1

懂了，在非CPU密集型阻塞的时候，应该利用多线程把CPU充分利用起来，这个时候适用多线程。那么在仅需要数据同步的情况下，并不适用多线程，而是更适合选择数据库锁定？缓存和多线程当然不是一回事儿，我只是打个不恰当的比方。我的本意是，在数据库查询操作的时候，抛开服务器压力暂且不说，如果CPU有空余，是否也可以使用多线程并发执行多个请求，只是我们有缓存这个更好更科学的选择？“java的web容器全部都是多线程的”是否可以理解为，所有的请求都是可以并发执行的？

Answer 2

懂了，在非CPU密集型阻塞的时候，应该利用多线程把CPU充分利用起来，这个时候适用多线程。那么在仅需要数据同步的情况下，并不适用多线程，而是更适合选择数据库锁定？缓存和多线程当然不是一回事儿，我只是打个不恰当的比方。我的本意是，在数据库查询操作的时候，抛开服务器压力暂且不说，如果CPU有空余，是否也可以使用多线程并发执行多个请求，只是我们有缓存这个更好更科学的选择？“java的web容器全部都是多线程的”是否可以理解为，所有的请求都是可以并发执行的？
应用层也可以加锁 ，数据库也可以加锁，加锁粒度不一样，不可一概而论，这和多线程也不是一回事。缓存和多线程当然不是一回事儿，我只是打个不恰当的比方。我的本意是，在数据库查询操作的时候，抛开服务器压力暂且不说，如果CPU有空余，是否也可以使用多线程并发执行多个请求，只是我们有缓存这个更好更科学的选择？
这根本不是个问题，因为你找不到非并发的服务器（Redis除外）。并发基本是服务器的通用解决方案。“java的web容器全部都是多线程的”是否可以理解为，所有的请求都是可以并发执行的？
不是可以，是“就是”。你见到的所有web服务器都是多线程并发的，这个你可以稍微看一眼tomcat源码就很容易看出来