性能测试中，我们常使用TPS来衡量服务的性能，这就需要我们在S内均匀的做到N个业务，而这里所要求的均匀，即保持固定频率，不是指间隔相同的时间，去做一些请求，因为实际处理请求的时间可能稍有不同，如果用固定的间隔时间去发送请求，那么所达到效果不见得是均匀，这里所述的固定频率或者说均匀实际上包含了本身请求处理的时间。
所以这里提供2种简单的方式：
（1）频率>=MS的：
采用JDK自带的Timer去处理：
jdk的timer核心源码：
private void mainLoop() {
while (true) {
try {
TimerTask task;
boolean taskFired;
synchronized(queue) {
// Wait for queue to become non-empty
while (queue.isEmpty() && newTasksMayBeScheduled)
queue.wait();
if (queue.isEmpty())
break; // Queue is empty and will forever remain; die
// Queue nonempty; look at first evt and do the right thing
long currentTime, executionTime;
task = queue.getMin();
synchronized(task.lock) {
if (task.state == TimerTask.CANCELLED) {
queue.removeMin();
continue; // No action required, poll queue again
}
currentTime = System.currentTimeMillis();
executionTime = task.nextExecutionTime;
if (taskFired = (executionTime<=currentTime)) {
if (task.period == 0) { // Non-repeating, remove
queue.removeMin();
task.state = TimerTask.EXECUTED;
} else { // Repeating task, reschedule
queue.rescheduleMin(
task.period<0 ? currentTime - task.period
: executionTime + task.period);
}
}
}
if (!taskFired) // Task hasn't yet fired; wait
queue.wait(executionTime - currentTime);
}
if (taskFired) // Task fired; run it, holding no locks
task.run();
} catch(InterruptedException e) {
}
}
}
timer用法：
timer.scheduleAtFixedRate(task, 4, 50); timer.cancel(); //达到自己需要发送的总时间可以去取消
（2）频率<MS：
由于JDK自带的Timer只能精确到1MS，所以如果发送间隔要求精确到微妙或者纳秒，可以使用JDK的另外一个类，例如控制到微妙：
ScheduledExecutorService newScheduledThreadPool = Executors.newScheduledThreadPool(1); newScheduledThreadPool.scheduleAtFixedRate(task, 0, 1000, TimeUnit.MICROSECONDS);
之前笔者不知道这个方式，所以提供一个简单的实现：
long sendIntervalInNano = 100 * 1000;
long totalExecuteTimeInSecond = 10; //控制最长发多久
long lastSendTime = System.nanoTime();
long endTime = lastSendTime + totalExecuteTimeInSecond*1000*1000*1000;
long offsite = 0; //补偿一些请求占用太长时间
while (lastSendTime < endTime) {
doThing();
long interval = sendIntervalInNano - (System.nanoTime() - lastSendTime)
+ offsite;
if (interval > 0) {
TimeUnit.NANOSECONDS.sleep(interval);
offsite = 0;
} else {
offsite = interval;
}
lastSendTime = System.nanoTime();
}
总结： 比较和JDK timer内部实现，核心的区别在于timer使用的是Object.wait来实现等待，而后者使用了sleep的方式。
具体区别：
（1）除了都可以被线程中断打断外，在等待的过程中，如果需要停止，前者可以优美的使用配套的Object.notify（Timer的cancel实现）,而使用sleep方式就没有中断之外的方法了。（Timer使用它的一个因素，更重要的是为了保持线程安全，用了同步块，顺其自然用了同步块锁的wait方法）
换句网友的说法比较贴切： 区别在于”(wait)同时又“积极”地等待条件发生改变”。
（2）sleep不会释放任何锁资源，而wait会释放对象锁资源，让其他线程获取这个锁，以便通知它可以继续执行，而
（3）sleep写在任何地方都可以，但是wait不行，wait必须在synchronized锁的锁范围内书写。
（4）sleep来源thread方法或者timeunit，wait来源于所有object,因为所有对象都有锁以提供支持。
题外话：
ScheduledExecutorService在task耗时大于调度间隔时间时，并不会使用更多的线程来并发，所以使用这种方式来达到预期的TPS不见得生效，所以最好直接使用thread pool来算好间隔时间，直接提交，同时不固定线程数，来弹性增加或者减少，虽然有线程大多挂掉的风险，但是还是比较准确的。需要结合具体运行情况来调整。
在保持一定的TPS的基础上，我们如果需要海量的TPS压力，就不能仅仅使用单台机器多线程去完成，且不说操作系统对线程数有限制，CPU本身提供的并发能力也有限。所以在单台机器创建的TPS已经无法满足需求时，我们要协同多台机器去做。
这里提供一种方法是使用持续集成平台jenkin的multiconfigure job来完成。构建多配置项目，选择N台结点，这样构建时，会同时并发N台结点做任务，当然这种方式创建的TPS和预想的会有细微差距：虽然是同时启动N台机器上的任务去做，但是难免因为机器不同等原因导致并发时间有差距。但是即使自己去实现一套多机器协同系统，也很难实现的比jenkin更好。
