A. 京東方目前電視顯示屏的技術怎麼樣
京東方的顯示技術一直在不斷創新當中。近年來京東方一直致力於8K超高清顯示的應用落地，並推出了ADS Pro、Mini ⌄LED/Micro LED等高端顯示產品，隨著OLED水平的不斷應用成熟，京東方在大尺寸OLED方面也有著深厚的技術儲備與量產能力。2022年，京東方強勢推出全球首款55英寸8K AMQLED顯示樣機。目前，全球知名電視終端品牌均搭載了京東方顯示屏。不論是從數量還是質量來看，京東方的電視顯示屏技術是走在世界前列的。
B. 關於ActiveMQ的配備怎麼解決
關於ActiveMQ的配置
目前常用的消息隊列組建無非就是MSMQ和ActiveMQ，至於他們的異同，這里不想做過多的比較。簡單來說，MSMQ內置於微軟操作系統之中，在部署上包含一個隱性條件：Server需要是微軟操作系統。（對於這點我並去調研過MSMQ是否可以部署在非微軟系統，比如:Linux，只是拍腦袋想了想，感覺上是不可以）。對於ActiveMQ，微軟系統和Linux都是可以部署的。從功能方面來說，一般最常用的就是：消息的收/發，感覺差異不大。從性能上來說，一般的說法是ActiveMQ略高。在穩定性上，個人感覺MSMQ更好。如果這兩種常用隊列都用過的同學，應該來說最大的差異在於：MSMQ如果要訪問遠程隊列（比如機器A上的程序訪問機器B上的隊列），會比較惡心。在數據量比較大的情況之下，一般來說隊列伺服器會專門的一台或者多台（多台的話，用程序去做熱備+負載比較方便，也不需要額外的硬體成本。簡單來說做法可以這樣：消息發送的時候隨機向著多台隊列伺服器上發送消息；接受的時候開多個線程去分別監聽；熱備方面，可以維護一個帶狀態的隊列連接池，如果消息收發失敗那麼將狀態置為不可用，然後起一個線程去定時監測壞的連接是否可用，這個過程一般情況下可以不用加鎖，為什麼，大家根據各自需要去取捨吧）。最近搞完了短彩信的網關連接服務，這兩種隊列我均使用了。大致的過程是這樣的：上層應用如果要發端彩信，那麼將消息直接發送至ActiveMQ（目前用的就是上面說的多台熱備+負載，因為實際中下行量非常大5千萬條/天以上），然後端彩信網關連接服務部署多套，每套均依賴本機的MSMQ。為什麼呢？用ActiveMQ的原因是：上層應用程序和網關連接服務彼此獨立，消息需要跨機訪問。用MSMQ的原因是：ActiveMQ中的數據是一條不分省的大隊列，網關連接服務需要按省流控，所以端彩信網關連接服務：首先把消息從ActiveMQ取出來，然後存至本機上的分省MSMQ，這樣做另外的一個好處就是：ActiveMQ不至於過多擠壓，他的數據會分攤到N台短彩信網關連接服務所部署的機器上的MSMQ之中，也就說MSMQ可以起到分攤數據和緩沖的作用。
在之前的隨筆中，已經介紹過MSMQ，現在先介紹一下ActiveMQ一些配置，目前好像ActiveMQ配置上的介紹還比較少。以下是自己總結一些相關資料，貼出來給大家共享
一）問題分析和解決
1）KahaDb和AMQ Message Store兩種持久方式如何選擇？
官方：
From 5.3 onwards - we recommend you use KahaDB - which offers improved scalability and recoverability over the AMQ Message Store.
The AMQ Message Store which although faster than KahaDB - does not scales as well as KahaDB and recovery times take longer.
非官方：
kaha文件系統實際上上是一個文件索引系統，有兩部分組成，一個是數據文件系統，由一個個獨立的文件組成，預設文件大小是32M大（可配置），另外一個是索引文件系統，記錄消息在數據文件中的位置信息以及數據文件中的空閑塊信息。數據文件是存儲到硬碟上的，索引文件是緩存在內存中的。所以這個存儲系統對大消息存儲有利，象我們的memberId之類的文本消息，實際上是浪費，索引比消息還大，哈。
我方分析：
推薦： Amq持久方式
理由：雖然官方推薦使用KahaDB持久方式，但其提到的優勢：可伸縮性和恢復性較好，對於我們實際的應用意義不大。從我們自己的使用經驗來看，KahaDB持久方式，Data文件是一個大文件（感覺文件過大後，造成隊列服務癱死的可能性會增大），從官網的相關配置（附錄1）也找不到哪裡可以設置數據的文件的最大Size。）而Amq持久方式可以設置Data文件最大Size，這樣可以保證即時消息積壓很多，Data文件也不至於過大。
2）錯誤：Channel was inactive for too long
解決方法：
在建立連接的Uri中加入： wireFormat.maxInactivityDuration=0
參考資源：
http://jinguo.iteye.com/blog/243153
You can do the following to fix the issues:
1) Append max inactivity ration to your Uri in the format below: wireFormat.maxInactivityDuration=0
2) Use the same Uri at the client side as well as at the server side
Regards,
如果不這樣設置，對應的錯誤會出現：
2008-05-07 09:22:56,343 [org.apache.activemq.ActiveMQConnection]-[WARN] Async exception with no exception listener: org.apache.activemq.transport.InactivityIOException: Channel was inactive for too long: localhost/127.0.0.1:61616
org.apache.activemq.transport.InactivityIOException: Channel was inactive for too long: localhost/127.0.0.1:61616
ActiveMQ的tcp url：tcp://localhost:61616後面要加入?wireFormat.maxInactivityDuration=0 這樣的參數，否則當一段時間沒有消息發送時會拋出 "Channel was inactive for too long"異常
3）錯誤：Wire format negotiation timeout: peer did not send his wire format.
解決方法：
1）關閉ActiveMqLog4j
打開：conf/log4j.properties
將：log4j.rootLogger=INFO, console, logfile
修改為：log4j.rootLogger=OFF
2）在建立連接的Uri中加入： =30000
例如北京的測試環境連接Uri：
tcp://192.168.199.80:61616?wireFormat.maxInactivityDuration=0&=30000&connection.AsyncSend=true
參考資源：
http://activemq.apache.org/javaxjmsjmsexception-wire-format-negociation-timeout-peer-did-not-send-his-wire-format.html
If you get exception like this,it can mean one of three things:
1. You're connecting to the port not used by ActiveMQ TCP transport
Make sure to check that you're connecting to the appropriate host:port
2. You're using log4j JMS appender and doesn't filter out ActiveMQ log messages
Be sure to read How do I use log4j JMS appender with ActiveMQ and more importantly to never send ActiveMQ log messages to JMS appender
3. Your broker is probably under heavy load (or network connection is unreliable), so connection setup cannot be completed in a reasonable time
If you experience sporadic exceptions like this, the best solution is to use failover transport, so that your clients can try connecting again if the first attempt fails. If you're getting these kind of exceptions more frequently you can also try extending wire format negotiation period (default 10 sec). You can do that by using wireFormat. property on the connection URL in your client.
For example
tcp://localhost:61616?wireFormat.=30000
will use 30 sec timeout.（貌似有問題！！！）
4）錯誤：Out of memory
解決方法：
1） 設置Java最大內存限制為合適大小：
Bin/activemq.bat 中ACTIVEMQ_OPTS=-Xmx512M（默認是512）
2）Activemq.xml配置節：systemUsage/ systemUsage配置大小合適，並且特別注意：大於所有rable desitination設置的memoryUsage之和。
備註：
1）尖括弧：「>」代表通配符
2）ACTIVEMQ_OPTS的配置〉=memoryUsage中配置〉=所有rable desitination設置之和
3）SystemUsage配置設置了一些系統內存和硬碟容量，當系統消耗超過這些容量設置時，amq會「slow down procer」，還是很重要的。
參考資料：
http://m.oschina.net/blog/26216
參考-- http://activemq.apache.org/javalangoutofmemory.html
對於MQ的內容實用是可管理和可配置的。首先需要判斷的是MQ的哪部分系統因內存不足而導致泄漏，是JVM，broker還是消費者、生產者？
一、內存管理
JVM內存管理：
1. 用bin/activemq命令在獨立JVM中運行broker。用-Xmx和-Xss命令即可（activemq.bat文件中修改ACTIVEMQ_OPTS選項參數即可）；
2. 默認情況下，MQ用512M的JVM；
broker內存管理：
1. broker使用的內存並不是由JVM的內存決定的。雖然受到JVM的限制，但broker確實獨立管理器內存；
2. systemUsage和destination的內存限制與broker內存息息相關；
3. MQ中內存的關系是：JVM->Broker->broker features;
4. 所有destination的內存總量不能超過broker的總內存；
消費者：
1. 由於消息大小可以配置，prefetch limit往往是導致內存溢出的主要原因；
2. 減少prefetch limit的大小，會減少消費者內存中存儲的消息數量；
生產者：
1. 除非消息數量超過了broker資源的限制，否則生產者不會導致內存溢出；
2. 當內存溢出後，生產者會收到broker的阻塞信息提示；
二、其他
將消息緩沖之硬碟：
1. 只有當消息在內存中存儲時，才允許消息的快速匹配與分發，而當消費者很慢或者離開時，內存可能會耗盡；
2. 當destination到達它的內存臨界值時，broker會用消息游標來緩存非持久化的消息到硬碟。
3. 臨界值在broker中通過memoryUsage和systemUsage兩個屬性配置，請參考activemq.xml；
4. 對於緩慢的消費者，當尚未耗盡內存或者轉變為生產者並發控制模式前，這個特性允許生產者繼續發送消息到broker；
5. 當有多個destination的時候，默認的內存臨界值可能被打破，而這種情況將消息緩存到硬碟就顯得很有意義；
6. precentUsage配置：使用百分比來控制內存使用情況；
多個線程：
1. 默認情況下，MQ每個destination都對應唯一的線程；
2. -Dorg.apache.activema.UseDedicatedTaskRunner=false（activemq.bat文件中修改ACTIVEMQ_OPTS選項參數即可），用線程池來限制線程的數量，從而減少內存消耗;
大數據傳輸：
1. destination policies--maxPageSize：控制進入內存中的消息數量；lazyDispatch:增加控制使用當前消費者列表的預取值；
2. 使用blogMessage或者streamsMessage類型來進行大量文件的傳輸；
泄漏JMS資源：
1. 當session或者procer或者consumer大量存在而沒有關閉的時候；
2. 使用PooledConnectionFactory；