关于synchronized的疑问

曹晓钢所介绍的文章刚刚看完，确实对我有所帮助，但里面所说的"A race condition occurs when multiple threads try to access a resource simultaneously. Simultaneous access will either cause a deadlock, corrupt data, or an explosion. "我以前测试过（o'reilly公司的java实例），但怎么也出现不了这种现象，不知道是不是CPU或操作系统的问题。

其实我真正搞不清楚的是线程的使用和必要性（不是理论上的必要性，而是真正操作中的必要性），看来还真象豆花香说的，我应该写写applets看看。

使用进程或线程编程可以使思路更自然。就像一道题可以用算术做也可以用方程做，但是使用方程显然更自然。

和这个有关系？好象加了以后更加不自然了，而且使用的太多会影响系统资源

如果是用java做程序,我想大部分的时候都不用想线程问题.
其实就是想,也只是要避免资源冲突而罢了(例如:写文件,更新数据库等).

java本身对线程的支持就很好.例如:servlet,ejb,jms等都是多线程的.

如果你把编程看得更人性化一点，你会发现确实是更自然了，进程和线程比较好的反映了真实世界的运作过程。
没有进程和线程，有些程序几乎是无法完成的。

曹晓钢推荐的那篇文章我看了一半，有个问题不明白：
就是讲静态方法的同步，一般的非静态方法的同步，其实就是同步this对象，而对于静态方法不是针对对象而言的，后来讲的那几句，感觉有点语焉不详，没看明白，不明白为什么后来又允许静态方法的同步了，最明显的就是lazy 单例模式 getInstance方法的那个synchronized，谁能说说这是怎么回事啊？

用getInstance找了一下，没找到，

mochow这个问题我的理解是这样的：
同步的本质是为了防止全局资源在进程或线程间的争用。对静态同步方法的疑惑也许是因为忘记了静态方法也是在进程或线程内执行的。因此不管是对象方法还是静态方法，只要涉及了全局资源的操作，就需要考虑同步的可能。

另外，这个疑惑还引出了一个问题：程序的执行机制和组织机制不能混为一谈。
1。程序的执行机制是，在CPU看来，它面对的程序只由两种东西（不管你是怎么组织程序的）构成，一个是存在于内存中的数据，一个是引导这些数据进行运算的机器指令。
2。程序的组织机制有两种：从人的角度看来，一是程序可以按面向过程的方式组织数据和代码，数据和代码是分离的，这种组织方式与CPU眼中的世界很相似；二是程序按照面向对象的方式组织，这种方式把数据和相关的操作紧密结合在一起。由于面向对象的组织方式是如此自然，以至于很多人“很自然”的就忘掉了进程或者线程的概念，因为这两个概念是面向过程组织方式的产物，跟面向对象的思维方式不合拍。在面向对象的世界里，“并发”一词可以更好的描述进程或线程所要表达的思想——也许java抛弃“thread(线程)”这个关键字而以“并发”作为关键字来实现同一思想更符合面向对象的特征。

那有进程编程的概念？？？对于java编程来说，一个虚拟机就是一个进程，不存在一个程序跨多个虚拟机运行控制的吧？

我有说过进程编程这样的字眼吗？呵呵，可能是你误解了。
进程是编程元素，但不是语言元素，在C/C++/Java中都是这样。而同步在C/C++里面是编程元素，在java里面同步则变成了一个语言元素。这样的好处是很明显的。我想表达的意思是，我希望在java里面使用“并发”作为语言元素来代替进程这样一个编程元素，这样将会使Java更具有面向对象的特征。

即使一个属性不是非常重要, 代码执行非常快,如果有线程冲突问题, 还是可能会带来严重的问题。不可以忽略不计的，很多多线程的经典例子，就是那以 i＋＋的同步问题来进行的，楼主的例子，不过是因为session的同步已经有web容器负责了而已罢了。如果session是一个自己创建的对象，并且是singleton的话，那么setAttribute的线程问题，就不得不考虑了。