網上關于刷卡機鏈接服務器超時,服務響應超時的刷卡知識比較多，也有關于刷卡機鏈接服務器超時的問題，今天第一pos網(www.jianshengsheng.cn)為大家整理刷卡常見知識，未來的我們終成一代卡神。

本文目錄一覽：

1、刷卡機鏈接服務器超時

2、pos機一直顯示連接服務器 pos機一直顯示連接服務器原因簡述

3、刷卡機顯示批送未完成怎么處理？

刷卡機鏈接服務器超時

問題描述：

部署在新搭建的服務器上的服務一直處于未響應狀態，每次發送請求等待若干秒之后只能接收到底層返回的超時報錯信息。

原因分析：

我們系統是一個服務化的單體應用，主要包含了一組業務服務和一個網關服務，外部請求一般都是先由網關服務做一些前置處理，然后根據請求格式和程序自定義配置路由到相應業務服務來進行業務處理，然后業務服務根據外部請求做完業務處理之后，也會將返回信息交給網關服務來統一返回。

所以正常情況下，一次服務調用引發的程序執行，網關服務與相應的業務服務配置好的日志文件都會有日志刷出來。

讓測試重現場景后，監控日志可以看到網關服務是有接收到請求并最終把請求路由到了業務服務的，但是業務服務卻始終沒有動靜，也就是時候沒看到有被調用的痕跡。嗯，有點奇怪~

可以先總結下問題：網關服務應該是沒問題的，反正接收到請求并且把請求轉發出去了，已經做好自己的事了。那么問題很有可能出在業務服務上了。

不過還是要排除其他影響，比如說下面最常見的三個：

1、服務器內存、CPU影響？

先用用top查看服務器資源使用情況，CPU、內存使用率實在看不出什么問題來

2、JVM內存影響？

有可能JVM一直在做GC，導致應用暫停時間過長。所以先用jstat看了下JVM各個分代的使用情況和GC的大概頻率（jstat -gccause pid 10000，這里當時忘記截圖了，以平時的經驗來看的話，都還比較正常，就先略過~）。

用jmap查看JVM內存使用情況（jmap -heap pid），新生代、老年大、持久帶使用率都還算不太高。

這里提一下，從下面的圖里可以看到老年代的標識是：concurrent mark-seeep generation，這就代表老年代使用的垃圾收集器是CMS，然后使用率已經接近70%了。有這么一種場景，當你老年代的垃圾回收器是CMS，然后你配置了JVM啟動參數：

-XX:CMSInitiatingOccupancyFraction=70-XX:+UseCMSInitiatingOccupancyOnly

這就代表著只要老年大使用率到達70%，JVM就會對老年代執行CMSGC來回收內存。如果老年代內存使用率一直大于等于70%，就會導致JVM頻繁CMSGC~

但是當時我們并沒有加這兩個參數，所以JVM是否要執行CMSGC是會實時動態計算的，老年代使用率接近70%并不是什么大問題。

3、相應線程哪里被阻塞了？

查看JVM線程狀態可以用jstack來打印線程快照（jstack pid）。將線程快照文件拉到本地來分析，發現在這個線程堆棧文件中，已經有5個請求業務服務的工作線程了，而且都是處于Object.wait()（這個就是在等待synchronized同步鎖喚醒的情況了）的狀態。

我們的各個業務服務呢，分別負責不同的業務處理部分（好像說了一句廢話）。然后業務服務與業務服務之間，是采用線程池隔離的機制。即每個業務服務是會起一個線程池去處理路由過來的請求。線程池的核心線程數和最大線程數都是5,當請求數大于5會將剩下的請求先丟到隊列中去，等待空閑線程來處理。

所以這就解釋了為什么會看到業務服務沒有被調用的現象，因為后續發的請求都丟到隊列里面去了，還沒來得及處理它們。

但是為什么前面的5個請求都會阻塞呢？看一下線程棧：

?????????????問號馬賽克????????????????????? nid=0x29808 in Object.wait() [0x0000000002e8c000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000007d801a670> (a org.apache.commons.pool.impl.GenericObjectPool$Latch) at java.lang.Object.wait(Object.java:503) at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1118) - locked <0x00000007d801a670> (a org.apache.commons.pool.impl.GenericObjectPool$Latch) at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106) at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044) at org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:111) at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:77) at org.mybatis.spring.transaction.SpringManagedTransaction.openConnection(SpringManagedTransaction.java:82) at org.mybatis.spring.transaction.SpringManagedTransaction.getConnection(SpringManagedTransaction.java:68) at org.apache.ibatis.executor.BaseExecutor.getConnection(BaseExecutor.java:338) at org.apache.ibatis.executor.SimpleExecutor.prepareStatement(SimpleExecutor.java:84) at org.apache.ibatis.executor.SimpleExecutor.doQuery(SimpleExecutor.java:62) at org.apache.ibatis.executor.BaseExecutor.queryFromDatabase(BaseExecutor.java:326) at org.apache.ibatis.executor.BaseExecutor.query(BaseExecutor.java:156) at org.apache.ibatis.executor.CachingExecutor.query(CachingExecutor.java:109) at org.apache.ibatis.executor.CachingExecutor.query(CachingExecutor.java:83) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.ibatis.plugin.Invocation.proceed(Invocation.java:49) ?????????????問號馬賽克????????????????????? at org.apache.ibatis.plugin.Plugin.invoke(Plugin.java:61) at com.sun.proxy.$Proxy19.query(Unknown Source) at org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:148) at org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:433) at com.sun.proxy.$Proxy13.selectList(Unknown Source) at org.mybatis.spring.SqlSessionTemplate.selectList(SqlSessionTemplate.java:230)

從這個線程堆棧可以看出是在查詢數據庫獲取連接的時候一直阻塞在那里了。所以從最開始的第一個請求卡頓到這里不能再往下執行，然后接下來四個也同樣卡在這個位置執行不了，再到后面的請求干脆就全緩存在隊列中來業務服務都無法進去。

但是為什么會阻塞在操作數據庫拿連接的地方呢，繼續往下挖，最終定位到GenericObjectPool。

GenericObjectPool是什么呢，它是一個對象池，而java很多池管理的概念，如線程池、數據庫連接池其實都是繼承自它的。因為這個是操作數據庫時的線程棧，而且堆棧的頂層是阻塞到GenericObjectPool的邏輯內，所以這時候懷疑是數據源的配置有問題。

檢查一下數據源配置，看到數據源的配置中的如下三個配置：

jdbc.maxActive = 0jdbc.maxIdle = 0jdbc.maxWait = -1

要知道maxActive（最大連接數）為0會讓你永遠從數據庫拿不到連接；

maxIdle（最大空閑連接數）為0會導致連接池中永遠沒有空閑連接數，對象都是在需要的時候創建、用完的時候又立馬destroy了；

而為maxWait（最大等待時間）-1，即如果拿不到連接會無限等待。尤其是在當被依賴的服務由于某些故障而響應極慢時，會有大量線程阻塞，最終導致線程耗盡，服務卡死，用戶請求被拒絕。

解決方案：

找到問題之后我們再把maxActive、maxIdle都設為80，maxWait設為3000，單位為毫秒（當然要根據具體情況設值），然后重啟數據源使其配置生效，再發請求調用業務服務就已經能正常處理了~

pos機一直顯示連接服務器 pos機一直顯示連接服務器原因簡述

pos機一直顯示連接服務器原因如耐碧旦下。

1、如果是移動POS機器，說明是內置流量卡已經失效，需要更換新流量卡或者充值；

2、如果是網慧銀線或者電話POS，請檢查網線連接是否順暢。

3、顯示一直在連接中，說明網昌擾絡有故障，連接不上，是網絡原因。

刷卡機顯示批送未完成怎么處理？

POS機顯示批上送的意思就是將你已經完成的刷卡數據傳送到銀行（不定期會出現屬于正常不必擔心），銀行收到你的數據后就會在晚上清算的時候將資金劃入你的賬戶，接收超時，接收通訊失敗主要是由于POS機的通訊不暢造成的，如果你的POS機是移動機器建議你將機器拿到信號好的地方，

如果你固定機器可能你的中國線不太穩定，重新將中國線連接一下就可以，這個現象屬于正常機具通信問題，不必擔心

以上就是關于刷卡機鏈接服務器超時,服務響應超時的知識，后面我們會繼續為大家整理關于刷卡機鏈接服務器超時的知識，希望能夠幫助到大家！

轉載請帶上網址：http://www.jianshengsheng.cn/shuaka/33714.html