大家好，感谢大家可以讨论、回答本帖。本人菜鸟一个，也有多年没开发了，也没实际开发过，我所问的是按照我自己的个人想法来提问的，所以很多问题说的不专业，还请谅解。
任务需求：
任务管理系统，是一个系统任务平台。
所遇到的问题是。在这个任务系统中有N个任务，那么也有N个人来抢任务做。
最开始的任务状态是0（没有进行操作）1表示已经进行操作。
任务流程
---->>
客户端请求任务----->>系统查询是否有状态为0的任务----->查询到状态修改为1----->>x返回给客户端。
那么问题在来了，由于系统的并发量很大。当第一个请求拿到一个为0的任务后还没来得及修改第二个或者第N个请求也拿到了相同的任务，那就造成了重复任务了。
解决方法：
synchronized ：
效率极低，容易造成系统崩溃。
缓存欲加载，提前加载好预定数量到内存中，查询直接查询缓存数据
缺陷：无法做分布式，或者来说 做分布式比较麻烦。
想请教各位大佬，这种业务应该怎么做。想了很久也没想出好的方案，该系统考虑做分布式。
该系统一秒可能会有几千个请求。
用一个任务队列保存所有任务，那么无论哪个线程拿到任务后将任务弹出队列，其他线程也就不会拿到重复任务，而且不需要去查询与修改状态。这样的同步队列可以自己去实现，也可以直接使用Concurrent包中提供的，建议使用jdk提供的，这样效率一般是没有问题的，如果还觉得效率不够，可以自己去实现队列，参考CAS或者其他的无锁思想
可以用阻塞队列等存放任务，然后线程池从里面拿任务来处理。阻塞队列符合happens-before规则。所以只会一个线程处理一个任务
可以使用redis做缓存，很多秒杀就是这样做的
从你的描述来看，用 synchronized 完全可以解决你的问题。
至于你说的所谓“效率极低”，那可能是你自己实现不好导致的。鉴于你也没有给出具体实现来，这个问题暂时也无法诊断。
一般来说，用了 synchronized，性能肯定有所降低，这是并发控制的本质所决定的。
所谓同步，其实就是在某些关键地方，让并发访问变成串行访问，以此保证数据的一致性。
它会降低一定的效率，但不应该是“极低”，极低只能说明你的控制有问题。
java中的并发同步安全性并不一定要用synchronized的，这个锁粒度太大，这个得看具体取舍，concurrent包里还有很多方案。redis可能会造成同步延时，
看你具体需求对这个要求是不是很高。有时候重复任务影响也不大。。。。。。。。。。。。。。。积分给我吧哈哈
建议使用消息队列MQ进行处理，既可以实现并发异步访问，又可以实现逐个处理的效果。
是web服务吗，为啥不直接用springmvc之类框架呢，任务直接入库，请求来了处理任务，对应记录状态置1