为什么感觉很多人都没考虑过线程安全问题？

有没有想过：
1、你的所有数据库操作curd方法都不是线程安全的
2、你的所有业务类都不是线程安全的
3、这不是用什么线程安全集合能解决的事情
4、业务是复杂的，需要同步的变量牵扯太多东西
5、考虑同步的时候又要去注意锁的粒度，范围

之所以没把线程安全当一回事，我觉得
1、并发量不高没有感觉到危机
2、出现了并发问题，但是由于业务的一些特性这些并发问题变成了小问题而且没有被察觉到
3、没有测试

实际上上面说的终究归咎于没有测试，当然提前要有这个意识，明白业务可能会出现什么问题。
举个例子来说：你在开开心心的写业务逻辑：

//变量

//方法{

    //进门
    //出门
}

方法很简单，进门之后出门，变量保存当前状态。
在你开开心心的打完收工的时候，有没有想过写的东西实际上就是一颗定时炸 弹：非线程安全
这个还只是一个非常简单的例子，可能你一会儿就看出来怎么去加锁让他变成线程安全的方法，这是件好事。

但是问题来了：这个例子只是非常初级的案例，回到各自的业务代码上来这种问题比比皆是。而且很多变量牵涉很多其他操作，你想把一个变量操作变成线程安全的，结果你发现这个变量又和其他变量有关。到最后你想把整个方法加锁，当然这种做法是极端不推荐的。

十几个方法操作同一个对象里面的若干个变量。给方法加锁？对象加锁？变量加锁？所多久？有没有想过这个加锁的快里面刚好有一个数据库操作，这个锁又会因为这个耗时的数据库操作影响多久？

虽然我也想把这些变量的操作方法写到对象里面去，然后给这个方法加锁。这是相当好的办法，效率也很高。
但是不是什么事情都事与愿违，我觉得我在线程安全问题上有些神经质了。
问题依然存在，不会因为你不神经质就让问题消失。你知道那里有个不定时炸 弹，在某个情况下可能就是因为一个小小的变量的值不正常导致流程错误，然后一堆人傻乎乎的被卡死在那里。

求指点，求打醒。我想知道大家在处理实际业务中的时候是怎么解决这种问题的，而不是在某个变量上加同步块。