这里有3个原因：
1.所有的woker thread(工作线程; 辅助线程)都在运行其他的job
2.scheduler(调度器)down了（关于这个down。我不太明确是shutdown了。。还是挂掉了。因此下文依旧用down。）
3.任务被安排在过去的某一时刻启动(此可能为代码错误)

我的

我的解决方法：修改quartz.properties文件中的org.quartz.threadPool.threadCount的值增大。（从原来的10增大到20），

　　　　　　最近公司加了好多定时任务，导致线程不够用，至此quartz挂掉。

以下来源于网上：

可以简单地通过配置quartz.properties文件中的org.quartz.threadPool.threadCount，来增加worker thread的数量(默认为10)。但是当整个 application/server/scheduler (调度器)挂掉的时候，这方法仍然是无效的。这种Quartz无法启动指定触发器情况，叫做 misfire(http://fanyi.baidu.com/#en/zh/misfire 以下统一用misfire，汉语无法贴切表达)。
你知道当这种情况发生的时候，Quartz能做些什么吗？ 其实，Quartz有许多的策略（叫misfire instructions，失火指示）可以处理问题，并且当你没有去想这方面问题的时候，它也有许多默认策略。但是为了使你的应用更加稳定和可预测（尤其是在高负载和可维护性上），你应该有意识的去确保triggers 和 jobs工作正常。

基于你用的trigger，会有不同的配置选项（对misfire instructions有效）。当然，不同的trigger也会使Quartz有不同的行为（叫做smart policy，明智的决策）。尽管文档中有misfire instructions的描述，但是我发现都很难理解它所想表达的意思，因此，我写下这篇简短的总结。

在我深入细节之前，还有一个配置需要说明下：org.quartz.jobStore.misfireThreshold(毫秒级)，默认是60000(一分钟)。它定义了trigger被认为是misfired了的时限。

基于默认配置，如果trigger应该在30秒以前被触发，那么很愉快地，Quartz就把它搞定了。这种延迟（delay）不能叫失火。

然而当trigger被发现，延迟了61秒时，那么专门的“失火处理者(misfire handler thread)”就会按照misfire instructions去处理它了。

为了测试效果，我们将这个时间设置为1000(即1秒)，这样就能很快的测试“失火”了。

第一个例子，是一个不需要重复触发的普通trigger，我们来看看普通trigger调度器是怎么处理“失火”，并让它运行一次的：

【原文：Simple trigger without repeating In our first example we will see how misfiring is handled by simple triggers scheduled to run only once:】

同样的trigger，但是明确设置了misfire instruction handler（失火处理者）:

为了测试，我将trigger设置为10秒前被调度(即当创建后，就已经晚于启动时间10秒)。在实际使用时，我们基本上永远不会这么设置。

换句话说，如果我们正确的设置了trigger，但是当需要被调度的时候，调度器down了或者没有空闲的worker thread了。那么，Quartz怎么处理这种extraordinary（罕见，古怪）的情况呢？

在第一段代码中，没有设置misfire instruction（so called smart policy is used in that case 这句不太会翻译。。。。）。

第二段代码中，明确指定了当misfire发生时，我们希望采取的行为。

来看下表：

普通trigger重复执行指定次数。这种情形更加复杂。想象一下，我们有一些需要重复执行指定次数的job：

在这个例子中，trigger从今天9点开始(startAt(dateOf(9, 0, 0))，共触发8次（第一次执行，和7次重复）。

按理，最后一次执行应该在下午4点被触发。假设由于某些原因，在9点和10点调度器没有执行job，并且直到10:15才被系统发现misfire，也就是misfire了2次。这种情况下，调度器会怎么样呢？

这是一个基于指定间隔、并重复无数次的trigger：

trigger应该从今天9点开始(startAt(dateOf(9, 0, 0))，每隔小时触发一次。然而调度器在9点到10点都没有执行job（比如关闭了系统、线程不够等等。。前面有介绍），并且在10点15时才被发现，misfire了2次。这种情况比那种执行执行次数的trigger更加普遍。

定时触发    CRON trigger

定时触发是Quartz中最常见的。它有另外两个有效的trigger：DailyTimeIntervalTrigger(比如每25分钟一次)和CalendarIntervalTrigger(比如5个月执行一次)。They support triggering policies not possible in both CRON and simple triggers.（不会译- -！），但是他们和CRON trigger一样，支持同样的misfire handling instructions（失火处理指令）。

这个例子是，trigger在每周一到周五的早上9点到下午5点间，每小时被触发一次。但是两次触发被misfire了，并且在10点15时，才发现这个情况。请注意，他们的失火指令效果与普通trigger是不同的：

QTZ-283Note: QTZ-283: MISFIRE_INSTRUCTION_IGNORE_MISFIRE_POLICY not working with JDBCJobStore - apparently there is a bug when JDBCJobStore is used, keep an eye on that issue. (在用JDBCJobStore 时，MISFIRE_INSTRUCTION_IGNORE_MISFIRE_POLICY 没有生效。显然，这是在使用JDBCJobStore时的一个bug，关注下。)

如你所有，根据实际的设定，不同的trigger会有不同的行为。此外，虽然它提供了smart policy（明智的决策），但是真正使用时，还是要取决于业务需求。

从本质上看，主要有三种策略：忽略，立即运行然后继续正常执行，忽略misfire的并等待下次执行。（ 原文： ignore, run immediately and continue and discard and wait for next. ）

它们有不同的应用场景：

当你需要确保每次调度任务都要被执行的时候，即时它意味着多个misfire的trigger会被触发，那么用ignore policies。试想一下，有一个任务，需要每小时，都根据上一小时的订单去生成报表。如果服务被关闭了8个小时，那你可能仍然是尽快得到那些报表的。这种情况下，配置ignore policies，调度器会尽快将那8小时的调度任务运行一遍的。尽管晚了几个小时，但是仍然是被执行了（最终报告到手了。^_^）。

当你需要任务被定期执行，并且当出现misfire的情况后立即运行一次的时候，那么使用now* policies。试想一下，一个任务是每分钟清空文件夹 /tmp。如果调度器在20分钟内繁忙，最后终于可以执行这个任务了，那么你肯定不会希望它执行20次的！一次就足够了，但是要尽快执行。而后，再回到正常的执行间隔--1分钟。

当你希望任务能在特定时间点运行的时候，使用next* policies不错。比如你需要在每个整点后15分钟抓取股票的价格。它们的变化非常快，然后现在已经整点后20分了，那么不必烦恼。你刚好错过了5分钟，但是现在你已经不在乎（那时候的价格）了。这时，一个时间间隙总好过一个不准确的值。这种情况Quartz只要跳过misfire的操作，等待下次执行就好了。