假设资源的优化配置是各领域发展的驱动力，那如何发现下一个方向或者机会点呢？不妨做一个矩阵，横向是业务领域，纵向是发展方式：

做一个积极的人

编码、改bug、提升自己

我有一个乐园，面向编程，春暖花开！

你好，JedisPoolConfig

Java中使用Jedis作为连接Redis的工具。在使用Jedis的也可以配置JedisPool连接池，JedisPool配置参数大部分是由JedisPoolConfig的对应项来赋值的。本文简单总结几个常用的配置，然后通过源码（版本jedis-3.1.0）的角度让你理解配置这些参数的原理。

首先了解一下池化（（对象池、数据库连接池、线程池等等））的一些思想和好处。方便后面对JedisPoolConfig的配置的理解。

池化的基本思想：

1、可以在初始化的时候创建一些对象，当有需要使用的时候不直接从池中获取，提高响应速度；

2、使用过的对象不进行销毁，保存起来，等下一次需要对象的时候，拿出来重复使用，减少频繁创建对象所造成的开销；

3、创建的对象统一保存，方面管理和维护。

池化好处总结：

1、提高响应的速度

2、降低资源的消耗

3、方便管理和维护

JedisPoolConfig配置说明

类图和源码解析

首先看一下类图：

• BaseGenericObjectPool：封装公共的配置的参数。

private long maxWaitMillis = DEFAULT_MAX_WAIT_MILLIS;
	// DEFAULT_MIN_EVICTABLE_IDLE_TIME_MILLIS = 1000L * 60L * 30L
    private long minEvictableIdleTimeMillis =
            DEFAULT_MIN_EVICTABLE_IDLE_TIME_MILLIS;

	// DEFAULT_TIME_BETWEEN_EVICTION_RUNS_MILLIS = -1L
 	private long timeBetweenEvictionRunsMillis =
            DEFAULT_TIME_BETWEEN_EVICTION_RUNS_MILLIS;

	// DEFAULT_NUM_TESTS_PER_EVICTION_RUN = 3
    private int numTestsPerEvictionRun =
            DEFAULT_NUM_TESTS_PER_EVICTION_RUN;

	// DEFAULT_TEST_ON_CREATE = false
    private boolean testOnCreate = DEFAULT_TEST_ON_CREATE;
	// DEFAULT_TEST_ON_BORROW = false
    private boolean testOnBorrow = DEFAULT_TEST_ON_BORROW;
	// DEFAULT_TEST_ON_RETURN = false
    private boolean testOnReturn = DEFAULT_TEST_ON_RETURN;
	// DEFAULT_TEST_WHILE_IDLE = false
    private boolean testWhileIdle = DEFAULT_TEST_WHILE_IDLE;
	//...
}

• GenericObjectPoolConfig：继承BaseGenericObjectPool，内部代码很简单，封装了GenericObjectPool的配置。主要是maxTotal、maxIdle、minIdle。
  此类不是线程安全的；它仅用于提供创建池时使用的属性。在创建单例的JedisPool 使用JedisPoolConfig需要注意线程安全问题，下面会有个demo介绍创建单例JedisPool。

public class GenericObjectPoolConfig<T> extends BaseObjectPoolConfig<T> {

    /**
     * The default value for the {@code maxTotal} configuration attribute.
     * @see GenericObjectPool#getMaxTotal()
     */
    public static final int DEFAULT_MAX_TOTAL = 8;
    // ...

	// DEFAULT_MAX_TOTAL = 8
    private int maxTotal = DEFAULT_MAX_TOTAL;
	// DEFAULT_MAX_IDLE = 8
    private int maxIdle = DEFAULT_MAX_IDLE;
	// DEFAULT_MIN_IDLE = 0
    private int minIdle = DEFAULT_MIN_IDLE;
    // ...
}

• JedisPoolConfig继承了上面的优良基因，然后又对其他的几个设置属性重新设值。

为了方便使用，Jedis提供了JedisPoolConfig，它继承了GenericObjectPoolConfig在空闲检测上的一些设置。

public class JedisPoolConfig extends GenericObjectPoolConfig {
  public JedisPoolConfig() {
    // defaults to make your life with connection pool easier :)
    setTestWhileIdle(true);
    setMinEvictableIdleTimeMillis(60000);
    setTimeBetweenEvictionRunsMillis(30000);
    setNumTestsPerEvictionRun(-1);
  }
}

配置参数解析

JedisPoolConfig中可以能够配置的参数有很多，连接池实现依赖apache 的commons-pool2。上面源码也大致列举了一些配置参数，下面在详细说明一下。

把池理解为工厂，池中的实例理解为工人，如下图，这样池中的很多参数理解起来就比较容易了。

Jedis连接就是连接池中JedisPool管理的资源，JedisPool保证资源在一个可控范围内，并且保障线程安全。使用合理的GenericObjectPoolConfig配置能够提升Redis的服务性能，降低资源开销。下列两表将对一些重要参数进行说明，并提供设置建议。

参数	说明	默认值	建议
maxTotal	资源池中的最大连接数	8	参见关键参数设置建议
maxIdle	资源池允许的最大空闲连接数	8	参见关键参数设置建议
minIdle	资源池确保的最少空闲连接数	0	参见关键参数设置建议
blockWhenExhausted	当资源池用尽后，调用者是否要等待。只有当值为true时，下面的maxWaitMillis才会生效。	true	建议使用默认值。
maxWaitMillis	当资源池连接用尽后，调用者的最大等待时间（单位为毫秒）。	-1（表示永不超时）	不建议使用默认值。
testOnBorrow	向资源池借用连接时是否做连接有效性检测（ping）。检测到的无效连接将会被移除。	false	业务量很大时候建议设置为false，减少一次ping的开销。
testOnReturn	向资源池归还连接时是否做连接有效性检测（ping）。检测到无效连接将会被移除。	false	业务量很大时候建议设置为false，减少一次ping的开销。
jmxEnabled	是否开启JMX监控	true	建议开启，请注意应用本身也需要开启。

空闲Jedis对象检测由下列四个参数组合完成，testWhileIdle是该功能的开关。

名称	说明	默认值	建议
testWhileIdle	是否开启空闲资源检测。	false	true
timeBetweenEvictionRunsMillis	空闲资源的检测周期（单位为毫秒）	-1（不检测）	建议设置，周期自行选择，也可以默认也可以使用下方JedisPoolConfig 中的配置。
minEvictableIdleTimeMillis	资源池中资源的最小空闲时间（单位为毫秒），达到此值后空闲资源将被移除。	180000（即30分钟）	可根据自身业务决定，一般默认值即可，也可以考虑使用下方JeidsPoolConfig中的配置。
numTestsPerEvictionRun	做空闲资源检测时，每次检测资源的个数。	3	可根据自身应用连接数进行微调，如果设置为 -1，就是对所有连接做空闲监测。

说明 可以在org.apache.commons.pool2.impl.BaseObjectPoolConfig中查看全部默认值。

关键参数设置建议

maxTotal（最大连接数）

想合理设置maxTotal（最大连接数）需要考虑的因素较多，如：

• 业务希望的Redis并发量；
• 客户端执行命令时间；
• Redis资源，例如nodes （如应用个数等） * maxTotal不能超过Redis的最大连接数；
• 资源开销，例如虽然希望控制空闲连接，但又不希望因为连接池中频繁地释放和创建连接造成不必要的开销。

假设一次命令时间，即borrow|return resource加上Jedis执行命令 （ 含网络耗时）的平均耗时约为1ms，一个连接的QPS大约是1000，业务期望的QPS是50000，那么理论上需要的资源池大小是50000 / 1000 = 50。

但事实上这只是个理论值，除此之外还要预留一些资源，所以maxTotal可以比理论值大一些。这个值不是越大越好，一方面连接太多会占用客户端和服务端资源，另一方面对于Redis这种高QPS的服务器，如果出现大命令的阻塞，即使设置再大的资源池也无济于事。

maxIdle与minIdle

maxIdle实际上才是业务需要的最大连接数，maxTotal 是为了给出余量，所以 maxIdle 不要设置得过小，否则会有new Jedis（新连接）开销，而minIdle是为了控制空闲资源检测。

连接池的最佳性能是maxTotal=maxIdle，这样就避免了连接池伸缩带来的性能干扰。但如果并发量不大或者maxTotal设置过高，则会导致不必要的连接资源浪费。

您可以根据实际总QPS和调用Redis的客户端规模整体评估每个节点所使用的连接池大小。

使用监控获取合理值

在实际环境中，比较可靠的方法是通过监控来尝试获取参数的最佳值。可以考虑通过JMX等方式实现监控，从而找到合理值。

上面参数配置：JedisPool资源池优化

创建JedisPool代码

// volatile 修饰
private static volatile JedisPool jedisPool = null;

private JedisPoolUtils(){
}

public static JedisPool getJedisPoolInstance() {
    // 使用双重检查创建单例
    if(null == jedisPool) {
        synchronized (JedisPoolUtils.class) {
            if(null == jedisPool) {
                JedisPoolConfig poolConfig = new JedisPoolConfig();
                poolConfig.setMaxTotal(10);
                poolConfig.setMaxIdle(10);
                poolConfig.setMinIdle(2);
                poolConfig.setMaxWaitMillis(30*1000);
                poolConfig.setTestOnBorrow(true);
                poolConfig.setTestOnReturn(true);
                poolConfig.setTimeBetweenEvictionRunsMillis(10*1000);
                poolConfig.setMinEvictableIdleTimeMillis(30*1000);
                poolConfig.setNumTestsPerEvictionRun(-1);
                jedisPool = new JedisPool(poolConfig,"localhost",6379);
            }
        }
    }
    return jedisPool;
}

实例创建和释放大致流程解析

根据流程进行源码解析

创建过程

使用pool.getResource()进行Jedis实例的创建。

//org.apache.commons.pool2.impl.GenericObjectPool#borrowObject(long)
public T borrowObject(final long borrowMaxWaitMillis) throws Exception {

    final boolean blockWhenExhausted = getBlockWhenExhausted();

    PooledObject<T> p = null;
    boolean create;
    final long waitTime = System.currentTimeMillis();

    while (p == null) {
        create = false;
        // 从空闲队列中获取
        p = idleObjects.pollFirst();
        if (p == null) {
            // 创建实例
            p = create();
            if (p != null) {
                create = true;
            }
        }
        // 吃资源是否耗尽
        if (blockWhenExhausted) {
            if (p == null) {
                // 等待时间小于0
                if (borrowMaxWaitMillis < 0) {
                    p = idleObjects.takeFirst();
                } else {
                    p = idleObjects.pollFirst(borrowMaxWaitMillis,
                                              TimeUnit.MILLISECONDS);
                }
            }
            if (p == null) {
                throw new NoSuchElementException(
                    "Timeout waiting for idle object");
            }
        } else {
            if (p == null) {
                throw new NoSuchElementException("Pool exhausted");
            }
        }
        if (!p.allocate()) {
            p = null;
        }

        if (p != null) {
            try {
                // 重新初始化要由池返回的实例。
                factory.activateObject(p);
            } catch (final Exception e) {

            }
        }
    }
    updateStatsBorrow(p, System.currentTimeMillis() - waitTime);

    return p.getObject();
}    

释放过程

从Jedis3.0版本后pool.returnResource()遭弃用,官方重写了Jedis的close方法用以代替；官方建议应用redis.clients.jedis#Jedis的close方法进行资源回收，官方代码如下：

 @Override
  public void close() {
    if (dataSource != null) {
      JedisPoolAbstract pool = this.dataSource;
      this.dataSource = null;
      if (client.isBroken()) {
        pool.returnBrokenResource(this);
      } else {
        pool.returnResource(this);
      }
    } else {
      super.close();
    }
  }

这里主要看：pool.returnResource(this);

//org.apache.commons.pool2.impl.GenericObjectPool#returnObject
public void returnObject(final T obj) {
    // 获取要释放的实例对象
    final PooledObject<T> p = allObjects.get(new IdentityWrapper<>(obj));

    if (p == null) {
        if (!isAbandonedConfig()) {
            throw new IllegalStateException(
                "Returned object not currently part of this pool");
        }
        return; // Object was abandoned and removed
    }
	// 将对象标记为返回池的状态。
    markReturningState(p);

    final long activeTime = p.getActiveTimeMillis();
	
    // 这里就和上面配置的参数有关系，释放的时候是否做连接有效性检测（ping）
    if (getTestOnReturn() && !factory.validateObject(p)) {
        try {
            destroy(p);
        } catch (final Exception e) {
            swallowException(e);
        }
        try {
            ensureIdle(1, false);
        } catch (final Exception e) {
            swallowException(e);
        }
        updateStatsReturn(activeTime);
        return;
    }
	
	// 检查空闲对象，如果最大空闲对象数小于当前idleObjects大小，则销毁
    final int maxIdleSave = getMaxIdle();
    if (isClosed() || maxIdleSave > -1 && maxIdleSave <= idleObjects.size()) {
        try {
            destroy(p);
        } catch (final Exception e) {
            swallowException(e);
        }
    } else {
        // 否则加入到空闲队列中，空闲队列是一个双端队列
        // getLifo 也和配置的参数有关，默认True
        if (getLifo()) {
            // last in first out，加到队头
            idleObjects.addFirst(p);
        } else {
            // first in first out ，加到队尾
            idleObjects.addLast(p);
        }
    }
    updateStatsReturn(activeTime);
}

上面创建和释放删除了一些代码，具体完整代码都是在GenericObjectPool类中。

小结，后悔有期

看完本文，应该大致对JedisPoolConfig有了一定的了解，指定里面的一些配置参数，并且能够基本的参数调优，以及实例资源的创建和释放的过程。

如果感谢兴趣的伙伴可以下载Jedis的源码进行阅读和学习，掌握了JedisPoolConfig的配置，其他池化框架的配置也是大同小异，举一反三！ 江湖不远，后会有期！

如果需要Reids相关的资源可以扫码下方二维码，里面有Redis的相关资源！

备注： 由于本人能力有限,文中若有错误之处,欢迎指正。

---

谢谢你的阅读，如果您觉得这篇博文对你有帮助，请点赞或者喜欢，让更多的人看到！祝你每天开心愉快！

---

Java编程技术乐园：一个分享编程知识的公众号。跟着老司机一起学习干货技术知识，每天进步一点点，让小的积累，带来大的改变！

扫描关注，后台回复【秘籍】，获取珍藏干货！ 99.9%的伙伴都很喜欢

©每天都在变得更好的阿飞云

数学建模高教社杯2015B “互联网+”时代的出租车资源配置论文解读

真题

首先展示一下2015B的原题是什么,如下

1B27002-B013解读

我们先大概的看看这篇论文的结构

模型假设

因为在现实中,许多情况没有我们想象的那么好,比如有些司机不使用打车软件,某些区域,比如学校,商场打车的比率更高,在没有打车软件的情况下,有些司机会挑选自己喜欢的路段接受乘客,而如果要把所有的因素全部考虑进去的话显然是一个非常大的工作量而且不太现实,所以作者给出了限定条件,也是每一篇建模论文都必须存在的部分 模型假设

问题解读

其他几个部分都是格式规范,就不仔细介绍了,可以自己去看看文章,接下来就进入正文部分
首先,这个题目是需要我们自己来收集数据的,所以对于各个问题,我们要抓住重点,第一步是明确应该如何收集数据
下面.我们就一步一步的来看这个问题

1.第一问

• 试建立合理的指标，并分析不同时空出租车资源的“供求匹配”程度。

---

数据采集

很明显,问题提到了不同时空,这说明了我们要收集是数据需要有一定的时间空间跨度
收集的数据对象则很明显是出租车
对于数据采集部分我觉得大多数人只要看的用心点就能分析出要收集什么样的数据,关键是对于不同时空这个限制条件,我们如何能找出具有代表性,方便我们建立模型的数据

本篇论文对于不同时空做出划分如下

• 时间
  • 高峰时段
  • 常规时段
• 空间
  • 市区
  • 郊区

下面是该论文对问题一的分析,显然对于本题,作者选取了里程利用率和供求比率作为指标

下面我们看看这为什么要选取这两个指标作为问题一的答案

指标确立

作者对于里程利用率给出了分析,语言简洁,思路清晰,我们可以看到里程利用率其实就是出租车载客的效率
载客效率高可以说明 供求关系紧张 因为司机载的乘客多,所以乘客相应的会难打到车
载客效率低可以说明 供求关系宽松 因为司机载的乘客少,所以乘客相应的会容易打到车

下面是作者对供求比率的分析
这也很好理解,总得来说就是供求程度一共有三种情况,抽象到数学公式就是η与1的大小比较

模型建立

很明显,这题就是对两个指标的分析
作者的思路是先确定两个指标的理想值

里程利用率理想值的确定

本文中作者从两个角度测量载客总里程

• 供给角度
• 需求角度

这个公式就是$$\frac{载客里程}{总里程}$$我觉得作者介绍的已经很清晰了

---

移项一下就得到了下面的等式
下面是从需求角度,也就是坐车的顾客角度出发的,虽然不知道为什么要这么假设,但是可以看懂,发现作者考虑的角度还是蛮周全的

如果上述两个角度的里程数相等,我们就可以推出理想值的里程利用率是什么
也就是作者在文中计算出的

供求比率理想值的确定

下图就是一个四边形区域,里面的黑点就是人,❉代表的是出租车
根据之前的公式$$供求比=\frac{市场客供总额}{需求总额}$$
该文章得出了如下的等式
很好理解,S就是出租车量,D就是顾客需求量,因为本文划分了n个四边形区域,所以累加求个和就好了

之前说过了供求关系分为三种情况,相应的作者做出了如下的公式
文章中的推导十分有条理,也很详细, 看看就知道了

下面的公式才是正确的公式,不过该文章没有给出推导过程,只是写了通过查阅相关资料,其实就是把${\eta }_{Ⅲ}$取了个倒数,不然会出问题,因为${\eta }_{Ⅲ}$本身是小于1的

接下来作者做的事情是把两个理想值作为平衡点,其他的值作相应的归一化处理
最后通过归一化后的结果,一个个二维的点,取他们到原点的举例作为不平衡度
这个也很好理解,归一化之后,离原点的距离越大,就说明了之前的数据距离平衡点越远,显然这样的点匹配度越差

模型求解

模型已经建立好了,下面的步骤就相对来说简单多了,本文作者选用了西安为案例

直接带入搜集到的数据,就可以得到了理想值
下面就是画图,分别从之前说过的时间空间角度绘制出供求比率的变化程度,然后加一点分析就好了

• 时间
  • 高峰时段
  • 常规时段
• 空间
  • 市区
  • 郊区
    分析什么的就是把图像大概说一说,总结一下第一问的结论,用普通人看的懂的语言表达出来

2.第二问

• 分析各公司的出租车补贴方案是否对“缓解打车难”有帮助？

---

在我看来这个问题就是考察的补贴方案对各个因素的影响,最后得出一个结论,有无帮助,根据现实来说,肯定是有的

先看看作者对问题二的分析
作者的思路很清晰,将补贴从下面两个角度考虑,最后对比有无补贴的情况就好了

• 补贴
  • 乘客
  • 司机

针对两个人群,作者先绘制出了推图像,求出了两种平均补贴金额

然后作者确立了软件的使用人数比例与补贴金额的关系.画了两张图

根据作者的问题分析,还需要确立意愿半径,意思就是司机在多大距离内原有来接单
作者查阅了耗油量,油价,结合补贴得出了表达式

上面这些都是很基本的操作,下面是模型的流程图

模型建立

看上去很复杂,其实就是从有没有使用打车软件来考虑,求出两种情况下的人均车辆占有率

作者在这里考虑的十分详细,接下里的文章里就对各个情况作出了说明,最后计算出w(缓解率),它的含义是该式用来表示使用补贴方案后与使用前相比的打车难的缓解程度

最后作者把各个时间段的缓解率绘制了个图像

又得出了一点分析,总的来说这道题的难度不大,主要考察的是思考问题的仔细程度

![在这里插入图片描述](https://img-blog.csdnimg.cn/20200715124936459.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dlYXJ5X1BK,size_16,color_FFFFFF,t_70

3.问题3

• 如果要创建一个新的打车软件服务平台，你们将设计什么样的补贴方案，并论证其合理性。

---

这道题跟第二问有着一定的联系,我们之前验证了政府给出的补贴方案是有利的,只不过这个问题我们需要求解出一个最优的补贴值,需要换一个角度思考问题,当然不能简单的套套第二问的公式
下面看看作者给出的问题三的分析

模型建立

这道题的思考空间大了许多,作者对于补贴的政策作出了更加详细的说明,并且从实际的角度论述了他们的可行性

作者从总体到局部进行分析,通过建立方程组来求解平均补贴

九个区域的平均补贴已经求解出来了,也就是空间的划分已经完成
除此之外,还需要考虑时间的划分,作者另外提取出了高峰时段,把高峰时段的补贴提高为2倍,得出了如下的等式

模型求解

针对确定好的模型,作者首先绘制出了自己手收集到的数据表,乘客司机分布图,最后求解出了动态补贴方案

后面两大块也是论文里面必须有的,看看作者是怎么说的吧

模型评价

模型的改进与推广

读后感

总的来说,这篇文章可以学习的点还是很多的,我们需要有一个严密的思维,并且在分析问题的时候考虑到各方面的因素,才可以在数学建模比赛中获得一个良好的成绩
切忌:虽然每一问之间都有着联系,但是对于每一问的侧重点不同,我们不能把之前的模型直接拿来用,不然就凉凉
对于这种社会型的问题来说,一般最后一问都会问的比较开放,这便需要我们的思维能力