• • 改cas的邏輯？

單點(diǎn)登錄的時候加跳轉(zhuǎn)來源參數(shù)，按照參數(shù)不同用不同的賬號密碼處理邏輯？
用戶數(shù)據(jù)也先別導(dǎo)入到一起，根據(jù)系統(tǒng)來源參數(shù)分開查詢，或者再加個系統(tǒng)字段？
一點(diǎn)想法。感覺這樣工作量也不小。

/**
*字節(jié)流下載
*/
public static void getContext(){

    System.getProperties().setProperty("https.proxyHost",
            "proxy.tencent.com");
    System.getProperties().setProperty("https.proxyPort", "8080");
    String url = "https://www.dong12.cn";
    InputStream in=null;
    FileOutputStream os=null;
    try {
        URL realUrl = new URL(url);
        URLConnection connection = realUrl.openConnection();
        connection.connect();
        in = connection.getInputStream();
        os=new FileOutputStream(new File("E:/poem3.html"));
        byte[] b=new byte[1024];
        int c=0;
        while ((c=in.read(b))!=-1) {
            os.write(b,0,c);
        }
    } catch (Exception e) {
        e.printStackTrace();
    }finally {
        try {
            if(os!=null){
                os.close();
            }
            if(in!=null){
                in.close();
            }
        } catch (IOException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
    }
}

json字符串存進(jìn)去？

bus=virtio

0000001不能算整數(shù)吧，python會報錯，通過int('0000001')`轉(zhuǎn)換一下。

FTP開發(fā)模式～～

嗯 我們做法是把js對應(yīng)的api封裝一下，直接調(diào)用js封裝的function，用callback做返回結(jié)果處理。

所有api都是 /api/user/{id} 這種格式的

不是很理解你哪里不理解，說下這個正則吧。
這個正則/(\d)(?=(\d{3})+\.)/的意思是捕獲.前面的3的倍數(shù)個數(shù)字前面的1個數(shù)字。
你的疑惑可能是因?yàn)闆]有看清楚(\d{3})+里面的+吧。

Buffer

var str = new Buffer('歡迎你');
str.toString();

你好,我想問一下你最后怎樣解決的

1、從第一圖和第三圖的曲線看，CPU高-->頻繁ygc造成
2、通常調(diào)整survivorRatio的效益不是那么明顯，整體收益不如調(diào)整新生代大小。從gc日志看，年老代最大的時候才使用600多M，是可以選擇擴(kuò)大新生代大小再觀察下是否還有問題。
3、新生代頻繁gc，這個跟你的服務(wù)性質(zhì)有關(guān)。提供查詢，導(dǎo)出等功能，導(dǎo)出功能的話，看實(shí)現(xiàn)的機(jī)制，如果是一次性load到內(nèi)存計算，最后再一次性寫到response，那么這段期間會占用內(nèi)存，如果同一時刻再多來幾次同類的導(dǎo)出請求，則新生代垃圾回收壓力大。從年老代使用峰值看，沒有內(nèi)存泄露，也就是這些對象基本在幾次ygc之后就回收了。于是就是新生代不斷產(chǎn)生對象，不斷回收部分，不斷晉升到年老代。之所以頻繁ygc，主要是垃圾回收速度跟不上新生對象創(chuàng)建速度導(dǎo)致。

理論上應(yīng)該是不行的。

這跟IDEA沒關(guān)系，用的是maven的依賴解決方案，maven將依賴分為幾個可見級別，不同級別的依賴關(guān)系對應(yīng)的打包結(jié)果不一樣。

單從打包結(jié)果來看，compile和runtime級別的依賴會打包進(jìn)入jar/war，test/testCompile/provide則不會。

從編譯結(jié)果看，compile級別的依賴從編譯-打包-運(yùn)行-測試都可見，runtime級別在編譯級別不可見，在運(yùn)行和測試可見(比如JDBC Driver，通常使用Class.forName()反射引用，所以編譯期間不需要，運(yùn)行時才需要)

test級別的幾個都好理解，只有跑自動化測試才需要(比如spock, junit, jmock等等)，打產(chǎn)品包的時候不需要。

懷疑你的rss字段不是數(shù)值類型的

請求超時...

有遇到在 execute shell script on remote host using ssh 執(zhí)行 node 報找不到命令，但是在其linux上執(zhí)行node是可以執(zhí)行的，知道怎么解決嗎？

每個群應(yīng)該有自己的URL吧？用@SendTo("/group/{groupId}")廣播消息不行嗎？

什么是壓縮類空間(Compressed Class space)?

首先壓縮類空間是元數(shù)據(jù)空間metaspace的一部分.

在64位平臺上, 指向類元數(shù)據(jù)的指針可以由32位偏移量 (帶有 UseCompressedOops) 表示。這由命令行標(biāo)志 UseCompressedClassPointers (默認(rèn)啟用) 控制。如果使用 UseCompressedClassPointers, 則類元數(shù)據(jù)的可用空間量將固定在 CompressedClassSpaceSize 數(shù)值上。如果 UseCompressedClassPointers 所需的空間超過 CompressedClassSpaceSize, 將拋出一個具有Compressed class space字樣的 java.lang.OutOfMemoryError異常。

操作: 增加參數(shù) CompressedClassSpaceSize 的大小以關(guān)閉 UseCompressedClassPointers選項(xiàng)。

注意: CompressedClassSpaceSize 的可接受大小有界限。例如, -XX:CompressedClassSpaceSize=4g, 超出可接受的界限將導(dǎo)致消息, 如CompressedClassSpaceSize=4294967296無效;必須介于1048576和3221225472之間。

注意: 有多種類元數(shù)據(jù) -klass 元數(shù)據(jù)和其他元數(shù)據(jù)。只有 klass 元數(shù)據(jù)存儲在由 CompressedClassSpaceSize 限定的空間中。其他元數(shù)據(jù)存儲在 Metaspace 中。

https://docs.oracle.com/javas...

相應(yīng)地:

CCSMN - 對應(yīng)軟件運(yùn)行過程中的最小歷史壓縮類空間大小
CCSMX - 對應(yīng)軟件運(yùn)行過程中的最大壓縮類空間大小
CCSC - 當(dāng)前壓縮類空間大小

什么是存活周期閾值(Tenuring threshold)?

TT: Tenuring threshold.
MTT: Maximum tenuring threshold.

Java 堆中的每個對象都有一個由垃圾回收 (GC) 算法使用的標(biāo)頭。新生代的空間收集器 (負(fù)責(zé)對象晉升) 使用此標(biāo)頭中的一些位來跟蹤幸存的集合對象的數(shù)量 (32 位 JVM 使用4位, 64 位可能更多)。

在新生代的空間收集過程中, 每個對象都被復(fù)制。可以將對象復(fù)制到生存空間 (在新生代 GC 之前為空) 或老年代空間。對于被復(fù)制的每個對象, GC 算法增加了它的年齡 (幸存的數(shù)量), 如果年齡高于當(dāng)前的 tenuring 閾值, 它將被復(fù)制 (晉升) 到老年代的空間。如果生存空間已滿, 對象也可以直接復(fù)制到老年代空間。

對象按下面的步驟移動:

1. 分配在新生代
2. 從新生代復(fù)制到生存空間(Minor GC)
3. 從生存空間到生存空間(Minor GC, 這可能發(fā)生數(shù)次)
4. 從生存空間(或可能新生代) 晉升到老年代空間(Minor GC或Full GC) 實(shí)際的 tenuring 閾值是由 JVM 動態(tài)調(diào)整的, 但MaxTenuringThreshold 設(shè)置了一個上限。

如果設(shè)置 MaxTenuringThreshold=0, 將立即升級所有對象。

MaxTenuringThreshold這個參數(shù)用于控制對象能經(jīng)歷多少次Minor GC才晉升到老年代.

TT與MTT的區(qū)別

在計算存活周期這個閾值時，hotspot會遍歷所有age的table，并對其所占用的大小進(jìn)行累積，當(dāng)累積的大小超過了survivor space的一半時，則以這個age作為新的存活周期閾值（TT），最后取age和MaxTenuringThreshold（MTT）中更小的一個值。

借助一個函數(shù)來實(shí)現(xiàn)替換的操作

import re

Str = ''' for(x as m){
       "select t.id as t from user;"        
       }
       
      for( z as C)
       '''
p = re.compile('\"(.*?)as(.*?)\"') 

# 替換函數(shù)，參數(shù)是一個Match對象，返回值是替換的結(jié)果。 
def repl(m):
    return '"' + m.group(1) + "bas" + m.group(2) +'"'

print p.sub(repl, Str)

運(yùn)行結(jié)果：

for(x as m){
       "select t.id bas t from user;"        
       }
       
      for( z as C)

原因：

分布在三臺機(jī)器的docker鏡像，它們的ip分別是鏡像中的ip，故是不能互相想問。

解決方法：

利用Docker Swarm，配置網(wǎng)絡(luò)。以下鏈接是一個具體方法。

http://blog.csdn.net/alaska_b...

當(dāng)然，也可以用K8s等工具解決。但是其本質(zhì)問題是網(wǎng)絡(luò)不通造成的。