format

@@ -148,7 +148,29 @@ public static <T> T string2Value(String value, Class<T> clazz) {
 >
 > 效果:在jvisalvm中该方法占用cpu时间有所降低，在本地自测belongsByString函数能提高10倍速度以上（在查找skn集合较大的情况下，优势更明显）。
 >
-> ![](问题总结/media/belongs.png)
+```
+    /**
+     * 查找是srcValue中否包含judgevalue
+     * @param srcValue
+     * @param judgeValue
+     * @return
+     */
+    private boolean belongs(String srcValue, String judgeValue) {
+        String[] belongArray = null;
+        if (judgeValue != null) {
+            belongArray = judgeValue.split(",");
+        }
+        return ArrayUtils.contains(belongArray, srcValue);
+    }
+
+    private boolean belongsByString(String srcValue, String judgeValue) {
+        if (StringUtils.isEmpty(judgeValue))
+            return false;
+        String tmp = "," + judgeValue + ",";
+        String tmp_key = "," + srcValue + ",";
+        return tmp.contains(tmp_key);
+    }
+```
 
 ### Redis值压缩优化
 
@@ -219,7 +241,9 @@ http://blog.itpub.net/22664653/viewspace-1063134/
 问题发现：
 购物车编辑场景，加大压力之后，tps未得到提高，且order、数据库压力均不高。将order服务直接连接数据库进行压测，发现tps有所提升。
 分析使用cobar时cobar的状态，下图是cobar的线程运行状态,可以看到目前有四个执行线程池，每个线程池的sql分析线程和执行线程均为8，目前活动的执行线程均为8，且队列中有部分sql在等待执行
+  
 ![](问题总结/media/cobar_before.png)
+  
 因此调整cobar的线程数
 ```
   <!-- 系统参数定义，服务端口、管理端口，处理器个数、线程池等。 -->
@@ -240,6 +264,7 @@ http://blog.itpub.net/22664653/viewspace-1063134/
 ```
 processors为线程池个数，通常和机器cpu个数对应，将processorExecutor执行线程数调整到16。
 下图是增大cobar 执行线程数后的运行状态，可以看到执行sql任务队列已无排队情况，此时使用cobar的tps也能与直连数据库持平。
+  
 ![](问题总结/media/cobar_after.png)