你們這個(gè)項(xiàng)目有秒殺嗎，怎么實(shí)現(xiàn)的？

所謂“秒殺”，就是網(wǎng)絡(luò)賣家發(fā)布一些超低價(jià)格的商品，所有買家在同一時(shí)間網(wǎng)上搶購的一種銷售方式。通俗一點(diǎn)講就是網(wǎng)絡(luò)商家為促銷等目的組織的網(wǎng)上限時(shí)搶購活動。由于商品價(jià)格低廉，往往一上架就被搶購一空，有時(shí)只用一秒鐘。

秒殺商品通常有兩種限制：庫存限制、時(shí)間限制。

需求：

（1）商家提交秒殺商品申請，錄入秒殺商品數(shù)據(jù)，主要包括：商品標(biāo)題、原價(jià)、秒殺價(jià)、商品圖片、介紹等信息

（2）運(yùn)營商審核秒殺申請

（3）秒殺頻道首頁列出秒殺商品（進(jìn)行中的）點(diǎn)擊秒殺商品圖片跳轉(zhuǎn)到秒殺商品詳細(xì)頁。

（4）商品詳細(xì)頁顯示秒殺商品信息，點(diǎn)擊立即搶購實(shí)現(xiàn)秒殺下單，下單時(shí)扣減庫存。當(dāng)庫存為0 或不在活動期范圍內(nèi)時(shí)無法秒殺。

（5）秒殺下單成功，直接跳轉(zhuǎn)到支付頁面（微信掃碼），支付成功，跳轉(zhuǎn)到成功頁，填寫收貨地址、電話、收件人等信息，完成訂單。

（6）當(dāng)用戶秒殺下單 5 分鐘內(nèi)未支付，取消預(yù)訂單，調(diào)用微信支付的關(guān)閉訂單接口，恢復(fù)庫存。

數(shù)據(jù)庫表分析

Tb_seckill_goods 秒殺商品表

Tb_seckill_order 秒殺訂單表

秒殺實(shí)現(xiàn)思路

? 秒殺技術(shù)實(shí)現(xiàn)核心思想是運(yùn)用緩存減少數(shù)據(jù)庫瞬間的訪問壓力！讀取商品詳細(xì)信息時(shí)運(yùn)用緩存，當(dāng)用戶點(diǎn)擊搶購時(shí)減少 redis 中的庫存數(shù)量，當(dāng)庫存數(shù)為 0 時(shí)或活動期結(jié)束時(shí)，同步到數(shù)據(jù)庫。 產(chǎn)生的秒殺預(yù)訂單也不會立刻寫到數(shù)據(jù)庫中，而是先寫到緩存，當(dāng)用戶付款成功后再寫入數(shù)據(jù)庫。

你們這個(gè)項(xiàng)目用的什么數(shù)據(jù)庫，數(shù)據(jù)庫有多少張表？

項(xiàng)目使用 mysql 數(shù)據(jù)庫，總共有 103 張表，其中商品表共計(jì)有 8 張。

項(xiàng)目部署做過嗎，能不能部署？

做過，可以部署。

項(xiàng)目服務(wù)器：集群部署

數(shù)據(jù)庫服務(wù)器：集群部署

Nginx 集群：負(fù)載均衡

單點(diǎn)登錄怎么做的，用別人知道原理嗎？

在分布式項(xiàng)目中實(shí)現(xiàn) session 共享，完成分布式系統(tǒng)單點(diǎn)登錄

3） Cookie 中共享 ticket

4） Redis 存儲 session

分布式系統(tǒng)共享用戶身份信息 session，必須先獲取 ticket 票據(jù)，然后再根據(jù)票據(jù)信息獲取 redis 中用戶身份信息。

實(shí)現(xiàn)以上 2 點(diǎn)即可實(shí)現(xiàn) session 共享。

目前項(xiàng)目中使用的 springsecurity + cas 來實(shí)現(xiàn)的單點(diǎn)登錄，cas 自動產(chǎn)生 ticket 票據(jù)信息，每次獲取用戶信息，cas 將會攜帶 ticket 信息獲取用戶身份信息。

支付做了嗎，支付寶還是微信，實(shí)現(xiàn)說下？

微信支付

微信支付：

1） 調(diào)用微信支付下單接口

2） 返回支付地址，生成二維碼

3） 掃描二維碼即可完成支付

問題： 微信支付二維碼是我們自己生成的，因此必須時(shí)刻監(jiān)控微信支付二維碼的狀態(tài)，確保支付成功。

緩存及優(yōu)化方面的面試問題

怎么提高 redis 緩存利用率？

1、從業(yè)務(wù)場景分析，預(yù)計(jì)會高頻率用到的數(shù)據(jù)預(yù)先存放到 redis 中，

2、可以定時(shí)掃描命中率低的數(shù)據(jù)，可以直接從 redis 中清除。

怎么實(shí)現(xiàn)數(shù)據(jù)量大、 并發(fā)量高的搜索

創(chuàng)建 solr 索引庫，數(shù)據(jù)量特別大時(shí)采用 solr 分布式集群

怎么分詞

使用第三方的分詞器 IKAnalyzer，會按照中國人用此習(xí)慣自動分詞。

seo 怎么優(yōu)化

使用 restful，或靜態(tài)頁這樣能更好的被搜索引擎收錄。

怎么加快訪問速度

硬件上加大網(wǎng)絡(luò)帶寬、和服務(wù)器內(nèi)存

代碼的處理：靜態(tài)頁面、緩存、優(yōu)化 sql、創(chuàng)建索引等方案

講到 redis 緩存的時(shí)候說不清楚

1、 redis 中項(xiàng)目中的應(yīng)用。

????????????1.主要應(yīng)用在門戶網(wǎng)站首頁廣告信息的緩存。因?yàn)殚T戶網(wǎng)站訪問量較大，將廣告緩存到 redis 中，可以降低數(shù)據(jù)庫訪問壓力，提高查詢性能。

????????????2.應(yīng)用在用戶注冊驗(yàn)證碼緩存。利用 redis 設(shè)置過期時(shí)間，當(dāng)超過指定時(shí)間后，redis 清理驗(yàn)證碼，使過期的驗(yàn)證碼無效。

????????????3.用在購物車模塊，用戶登陸系統(tǒng)后，添加的購物車數(shù)據(jù)需要保存到 redis 緩存中。

2、 技術(shù)角度分析：

? ??????2.1 內(nèi)存如果滿了，采用 LRU 算法進(jìn)行淘汰。

????????2.2Redis 如何實(shí)現(xiàn)負(fù)載的？采用 Hash 槽來運(yùn)算存儲值，使用 CRC16 算法取模運(yùn)算，來保證負(fù)載問題。

????????2.3Redis 緩存穿透問題？將數(shù)據(jù)查詢出來如果沒有強(qiáng)制設(shè)置空值，并且設(shè)置過期時(shí)間，減少頻繁查詢數(shù)據(jù)庫。

能講下 redis 的具體使用場景嗎？使用 redis 存儲長期不改變的數(shù)據(jù)完全可以使用也看靜態(tài)化，那么你們當(dāng)時(shí)是為什么會使用 redis？

redis 在項(xiàng)目中應(yīng)用：

????????1.主要應(yīng)用在門戶網(wǎng)站首頁廣告信息的緩存。因?yàn)殚T戶網(wǎng)站訪問量較大，將廣告緩存到 redis 中，可以降低數(shù)據(jù)庫訪問壓力，提高查詢性能。

????????2.應(yīng)用在用戶注冊驗(yàn)證碼緩存。利用 redis 設(shè)置過期時(shí)間，當(dāng)超過指定時(shí)間后，redis 清理驗(yàn)證碼，使過期的驗(yàn)證碼無效。

????????3.用在購物車模塊，用戶登陸系統(tǒng)后，添加的購物車數(shù)據(jù)需要保存到 redis 緩存中。

使用 redis 主要是減少系統(tǒng)數(shù)據(jù)庫訪問壓力。從緩存中查詢數(shù)據(jù)，也提高了查詢性能，挺高用戶體驗(yàn)度。

redis 中對一個(gè) key 進(jìn)行自增或者自減操作，它是原子性的嗎？

是原子性的。對于 Redis 而言，命令的原子性指的是：一個(gè)操作的不可以再分，操作要么執(zhí)行，要么不執(zhí)行。Redis 的操作之所以是原子性的，是因?yàn)?Redis 是單線程的。對 Redis 來說，執(zhí)行 get、set 以及 eval 等 API，都是一個(gè)一個(gè)的任務(wù)，這些任務(wù)都會由Redis 的線程去負(fù)責(zé)執(zhí)行，任務(wù)要么執(zhí)行成功，要么執(zhí)行失敗，這就是 Redis 的命令是原子性的原因。Redis 本身提供的所有 API 都是原子操作，Redis 中的事務(wù)其實(shí)是要保證批量操作的原子性。

你們項(xiàng)目中使用到的數(shù)據(jù)庫是什么？你有涉及到關(guān)于數(shù)據(jù)庫到建庫建表操作嗎？數(shù)據(jù)庫創(chuàng)建表的時(shí)候會有哪些考慮呢？

項(xiàng)目中使用的是 MySQL 數(shù)據(jù)庫，數(shù)據(jù)庫創(chuàng)建表時(shí)要考慮

a、大數(shù)據(jù)字段最好剝離出單獨(dú)的表，以便影響性能

b、使用 varchar，代替 char，這是因?yàn)?varchar 會動態(tài)分配長度，char 指定為 20，即時(shí)你存儲字符“1”，它依然是 20 的長度

c、給表建立主鍵，看到好多表沒主鍵，這在查詢和索引定義上將有一定的影響

d、避免表字段運(yùn)行為 null，如果不知道添加什么值，建議設(shè)置默認(rèn)值，特別 int 類型，比如默認(rèn)值為 0，在索引查詢上，效率立顯。

e、建立索引，聚集索引則意味著數(shù)據(jù)的物理存儲順序，最好在唯一的，非空的字段上建立，其它索引也不是越多越好，索引在查詢上優(yōu)勢顯著，在頻繁更新數(shù)據(jù)的字段上建立聚集索引，后果很嚴(yán)重，插入更新相當(dāng)忙。

f、組合索引和單索引的建立，要考慮查詢實(shí)際和具體模式

mysql 中哪些情況下可以使用索引，哪些情況不能使用索引？mysql 索引失效的情形有哪些？

使用索引：

a、 為了快速查找匹配 WHERE 條件中涉及到列。

b、 如果表有一個(gè) multiple-column 索引，任何一個(gè)索引的最左前綴可以通過使用優(yōu)化器來查找行

c、 當(dāng)運(yùn)行 joins 時(shí)，為了從其他表檢索行。MySql 可以更有效的使用索引在多列上如果他們聲明的類型和大小是一樣的話。在這個(gè)環(huán)境下，VARCHAR 和 CHAR 是一樣的如果他們聲明的大小是一樣的

d、 為了找到 MIN() or MAX()的值對于一個(gè)指定索引的列 key_col.

總之，就是經(jīng)常用到的列就最好創(chuàng)建索引。

不能使用引用：

????a) 數(shù)據(jù)唯一性差（一個(gè)字段的取值只有幾種時(shí)）的字段不要使用索引

????????比如性別，只有兩種可能數(shù)據(jù)。意味著索引的二叉樹級別少，多是平級。這樣的二叉樹查找無異于全表掃描

b) 頻繁更新的字段不要使用索引

????????比如 logincount 登錄次數(shù)，頻繁變化導(dǎo)致索引也頻繁變化，增大數(shù)據(jù)庫工作量，降低效率

c) 字段不在 where 語句出現(xiàn)時(shí)不要添加索引,如果 where 后含 IS NULL /IS NOT NULL/ like ‘%輸入符%’等條件，不建議使用索引只有在 where 語句出現(xiàn)，mysql 才會去使用索引

d） where 子句里對索引列使用不等于（<>），使用索引效果一般

索引失效：

a.如果條件中有 or，即使其中有條件帶索引也不會使用(這也是為什么盡量少用 or 的原因)

注意：要想使用 or，又想讓索引生效，只能將 or 條件中的每個(gè)列都加上索引

b.對于多列索引，不是使用的第一部分，則不會使用索引

c.like 查詢是以%開頭

d.如果列類型是字符串，那一定要在條件中將數(shù)據(jù)使用引號引用起來 否則不使用索引

e.如果 mysql 估計(jì)使用全表掃描要比使用索引快,則不使用索引

8，java 中的多線程在你們的這個(gè)項(xiàng)目當(dāng)中有哪些體現(xiàn)？

a，后臺任務(wù)：如定時(shí)向大量(100W 以上)的用戶發(fā)送郵件；定期更新配置文件、任務(wù)調(diào)度

(如 quartz)，一些監(jiān)控用于定期信息采集

b， 自動作業(yè)處理：比如定期備份日志、定期備份數(shù)據(jù)庫

c， 異步處理：如發(fā)微博、記錄日志

Redis 分布式鎖理解

回答：

實(shí)現(xiàn)思想

獲取鎖的時(shí)候，使用 setnx 加鎖，并使用 expire 命令為鎖添加一個(gè)超時(shí)時(shí)間，超過該時(shí)間則自動釋放鎖，鎖的 value 值為一個(gè)隨機(jī)生成的 UUID，通過此在釋放鎖的時(shí)候進(jìn)行判斷。

獲取鎖的時(shí)候還設(shè)置一個(gè)獲取的超時(shí)時(shí)間，若超過這個(gè)時(shí)間則放棄獲取鎖。

釋放鎖的時(shí)候，通過 UUID 判斷是不是該鎖，若是該鎖，則執(zhí)行 delete 進(jìn)行鎖釋放。

Redis 怎么設(shè)置過期的？項(xiàng)目過程中，使用了哪一種持久化方式

回答：

設(shè)置過期：

this.redisTemplate.expire("max",tempTime,TimeUnit.SECONDS);

持久化方式：Redis 默認(rèn)的 RDB 方式

項(xiàng)目添加 Redis 緩存后，持久化具體怎么實(shí)現(xiàn)的。

答：

RDB：保存存儲文件到磁盤；同步時(shí)間為 15 分鐘，5 分鐘，1 分鐘一次，可能存在數(shù)據(jù)丟失問題。

AOF：保存命令文件到磁盤；安全性高，修改后立即同步或每秒同步一次。

上述兩種方式在我們的項(xiàng)目中都有使用到，在廣告輪播的功能中使用了 redis 緩存，先從 redis 中獲取數(shù)據(jù)，無數(shù)據(jù)后從數(shù)據(jù)庫中查詢后保存到 redis 中

采用默認(rèn)的 RDB 方式，在廣告輪播的功能中使用了 redis 緩存，先從 redis 中獲取數(shù)據(jù)，無數(shù)據(jù)就從數(shù)據(jù)庫中查詢后再保存到 redis 中

redis 能夠存儲的數(shù)據(jù)類型有哪幾種？?

Redis 通過 SpringDataRedis 訪問的. Redis 支持五種數(shù)據(jù)類型：string（字符串），hash（哈希），list（列表），set（集合）及 zset(sorted set： 有序集合)

怎樣進(jìn)行程序性能調(diào)優(yōu)

系統(tǒng)性能就是兩個(gè)事：

Throughput ，吞吐量。也就是每秒鐘可以處理的請求數(shù)，任務(wù)數(shù)。

Latency， 系統(tǒng)延遲。也就是系統(tǒng)在處理一個(gè)請求或一個(gè)任務(wù)時(shí)的延遲。

那么 Latency 越好，能支持的 Throughput 就會越高。因?yàn)?Latency 短說明處理速度快，于是就可以處理更多的請求。

提高吞吐量：

????????分布式集群，模塊解藕，設(shè)計(jì)模式

系統(tǒng)延遲：

????????異步通信

數(shù)據(jù)庫設(shè)計(jì)的面試問題

你有了解 mysql 的隔離級別嗎？mysql 默認(rèn)的隔離級別是什么？

數(shù)據(jù)庫事務(wù)的隔離級別有四種，隔離級別高的數(shù)據(jù)庫的可靠性高，但并發(fā)量低，而隔離級別低的數(shù)據(jù)庫可靠性低，但并發(fā)量高，系統(tǒng)開銷小。

1. READ UNCIMMITTED（未提交讀）

2. READ COMMITTED（提交讀）

3. REPEATABLE READ（可重復(fù)讀）

4. SERIALIZABLE（可串行化）

mysql 默認(rèn)的事務(wù)處理級別是'REPEATABLE-READ',也就是可重復(fù)讀。

sql 語句中關(guān)于查詢語句的優(yōu)化你們是怎么做的？

1、應(yīng)盡量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進(jìn)行全表掃描。

2、對查詢進(jìn)行優(yōu)化，應(yīng)盡量避免全表掃描，首先應(yīng)考慮在 where 及 order by 涉及的列上建立索引。

3、應(yīng)盡量避免在 where 子句中對字段進(jìn)行 null 值判斷，否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描

4、盡量避免在 where 子句中使用 or 來連接條件，否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描

5、in 和 not in 也要慎用，否則會導(dǎo)致全表掃描

6、應(yīng)盡量避免在 where 子句中對字段進(jìn)行表達(dá)式操作，這將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描。

7、應(yīng)盡量避免在 where 子句中對字段進(jìn)行函數(shù)操作，這將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描

8、不要在 where 子句中的“=”左邊進(jìn)行函數(shù)、算術(shù)運(yùn)算或其他表達(dá)式運(yùn)算，否則系統(tǒng)將可能無法正確使用索引。

9、在使用索引字段作為條件時(shí)，如果該索引是復(fù)合索引，那么必須使用到該索引中的第一個(gè)字段作為條件時(shí)才能保證系統(tǒng)使用該索引，否則該索引將不會被使 用，并且應(yīng)盡可能的讓字段順序與索引順序相一致。

10、索引并不是越多越好，索引固然可以提高相應(yīng)的 select 的效率，但同時(shí)也降低了insert 及 update 的效率，因?yàn)?insert 或 update 時(shí)有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。

11、盡可能的使用 varchar/nvarchar 代替 char/nchar ，因?yàn)槭紫茸冮L字段存儲空間小，可以節(jié)省存儲空間，其次對于查詢來說，在一個(gè)相對較小的字段內(nèi)搜索效率顯然要高些。

12、任何地方都不要使用 select * from t ，用具體的字段列表代替“*”，不要返回·用不到的任何字段。

mysql 索引失效的場景有哪些？like 做模糊查詢的時(shí)候會失效嗎？

1.WHERE 字句的查詢條件里有不等于號（WHERE column!=…），MYSQL 將無法使用索引

2.類 似地， 如果 WHERE 字 句的查 詢條件 里使用 了函數(shù) （如： WHERE DAY(colu mn)=…）， MYSQL 將 無法使 用索引

3.在 JOIN 操 作中（需要 從多個(gè) 數(shù)據(jù)表 提取數(shù) 據(jù)時(shí) ），MYSQL 只有 在主鍵 和外鍵 的數(shù) 據(jù)類型 相同時(shí) 才能使 用索引 ，否則即使建立了索引也不會使用

4.如 果 WHERE 子 句的查 詢條件 里使用 了比較 操作 符 LIKE 和 REGEXP， MYSQL只 有 在搜 索 模板 的第 一 個(gè)字 符不 是 通配 符的 情況 下 才能 使用 索 引。 比如 說 ，如 果查 詢條件 是 LIKE? 'abc%',MYSQL 將使 用索引 ；如果 條件 是 LIKE? '%abc'，MYSQ L 將 不使用 索引。

5.在 ORDER BY 操 作中， MYSQL 只 有在排 序條件 不是一 個(gè)查詢 條件表 達(dá)式的 情況 下 才使 用 索引 。盡 管 如此 ，在 涉 及多 個(gè)數(shù) 據(jù)表 的 查詢 里， 即 使有 索引 可 用， 那些 索引在 加快 ORDER BY 操作方 面也沒 什么作 用。

6.如 果某個(gè) 數(shù)據(jù)列 里包含 著許多 重復(fù)的 值，就 算為它 建立了 索引也 不會有 很好的 效果 。比如 說，如 果某個(gè) 數(shù)據(jù)列 里包含 了凈是 些諸如 “0/1”或“Y/N”等 值，就 沒有必 要為 它創(chuàng)建 一個(gè)索引。

7.索引有用 的情況下就太 多了?；局灰⒘怂饕?，除了上面提到的索引不會使用的情況下之外 ，其他情況只要是使用在 WHERE條件里 ，ORDER? BY字段 ，聯(lián)表字段，一般都是有效 的。 建立索引要的就 是有效果。不然還用它干 嗎？如果不能確定在某 個(gè)字段上建立的索引是否有效果 ， 只要實(shí)際進(jìn)行測試下比較下執(zhí)行 時(shí)間就知道。

8.如 果條件 中有 or(并且其 中有 or 的條 件是不 帶索引 的)， 即使其 中有條 件帶索 引也 不會使 用(這 也是為 什么盡 量少用 or 的原 因)。 注意： 要想使用 or，又想讓索 引生 效，只能將 or 條件 中的每 個(gè)列都 加上索 引

9.如果 列類 型是 字符 串， 那一 定要 在條 件中 將數(shù) 據(jù)使 用引 號引 用起 來,否則 不使 用索 引

10.如 果 mysql 估計(jì) 使用全 表掃描 要比使 用索引 快,則不 使用索 引

問 題二： Like 模糊查詢，建立索引會失效

項(xiàng)目中關(guān)于表結(jié)構(gòu)拆分，你們是業(yè)務(wù)層面的拆分還是表結(jié)構(gòu)層面的拆分？

表結(jié)構(gòu)層面的拆分。通過 mycat 數(shù)據(jù)庫中間件完成數(shù)據(jù)庫分表操作。

業(yè)務(wù)層面也有拆分，比如商品模塊拆分成 8 張表來實(shí)現(xiàn)存儲

有了解過大數(shù)據(jù)層面的分庫分表嗎？以及 mysql 的執(zhí)行計(jì)劃嗎？

分庫

通過 Mycat 結(jié)點(diǎn)來管理不同服務(wù)器上的數(shù)據(jù)庫，每個(gè)表最多存 500 萬條記錄

分表

重直切割，水平切割

MySql 提供了 EXPLAIN 語法用來進(jìn)行查詢分析，在 SQL 語句前加一個(gè)"EXPLAIN"即可。mysql 中的 explain 語法可以幫助我們改寫查詢，優(yōu)化表的結(jié)構(gòu)和索引的設(shè)置，從而最大地提高查詢效率。

有了解過數(shù)據(jù)庫中的表級鎖和行級鎖嗎？樂觀鎖和悲觀鎖你有哪些了解？

MySQL 的鎖機(jī)制比較簡單，其最顯著的特點(diǎn)是不同的存儲引擎支持不同的鎖機(jī)制。比如，MyISAM 和 MEMORY 存儲引擎采用的是表級鎖（table-level locking）；InnoDB存儲引擎既支持行級鎖（ row-level locking），也支持表級鎖，但默認(rèn)情況下是采用行級鎖。

MySQL 主要的兩種鎖的特性可大致歸納如下:

表級鎖： 開銷小，加鎖快；不會出現(xiàn)死鎖(因?yàn)?MyISAM 會一次性獲得 SQL 所需的全部鎖)；鎖定粒度大，發(fā)生鎖沖突的概率最高,并發(fā)度最低。

行級鎖： 開銷大，加鎖慢；會出現(xiàn)死鎖；鎖定粒度最小，發(fā)生鎖沖突的概率最低,并發(fā)度也最高。

樂觀鎖：通過 version 版本字段來實(shí)現(xiàn)

悲觀鎖：通過 for update 來實(shí)現(xiàn)

Mysql 優(yōu)化有沒有工具

回答：

三個(gè) MySQL 性能測試工具：The MySQL Benchmark Suite、MySQL super-smack、MyBench。除了第一個(gè)為 MySQL 性能測試工具，其他兩個(gè)都為壓力測試工具。

你們項(xiàng)目中使用到的數(shù)據(jù)庫是什么？你有涉及到關(guān)于數(shù)據(jù)庫到建庫建表操作嗎？數(shù)據(jù)庫創(chuàng)建表的時(shí)候會有哪些考慮呢？

項(xiàng)目中使用的是 MySQL 數(shù)據(jù)庫，

數(shù)據(jù)庫創(chuàng)建表時(shí)要考慮

a、大數(shù)據(jù)字段最好剝離出單獨(dú)的表，以便影響性能

b、使用 varchar，代替 char，這是因?yàn)?varchar 會動態(tài)分配長度，char 指定為 20，即時(shí)你存儲字符“1”，它依然是 20 的長度

c、給表建立主鍵，看到好多表沒主鍵，這在查詢和索引定義上將有一定的影響

d、避免表字段運(yùn)行為 null，如果不知道添加什么值，建議設(shè)置默認(rèn)值，特別 int 類型，比如默認(rèn)值為 0，在索引查詢上，效率立顯。

e、建立索引，聚集索引則意味著數(shù)據(jù)的物理存儲順序，最好在唯一的，非空的字段上建立，其它索引也不是越多越好，索引在查詢上優(yōu)勢顯著，在頻繁更新數(shù)據(jù)的字段上建立聚集索引，后果很嚴(yán)重，插入更新相當(dāng)忙。

f、組合索引和單索引的建立，要考慮查詢實(shí)際和具體模式

mysql 中哪些情況下可以使用索引，哪些情況不能使用索引？mysql 索引失效的情形有哪些？

使用索引：

a、 為了快速查找匹配 WHERE 條件中涉及到列。

b、 如果表有一個(gè) multiple-column 索引，任何一個(gè)索引的最左前綴可以通過使用優(yōu)化器來查找行

c、 當(dāng)運(yùn)行 joins 時(shí)，為了從其他表檢索行。MySql 可以更有效的使用索引在多列上如果他們聲明的類型和大小是一樣的話。在這個(gè)環(huán)境下，VARCHAR 和 CHAR 是一樣的如果他們聲明的大小是一樣的

d、 為了找到 MIN() or MAX()的值對于一個(gè)指定索引的列 key_col.

????????????總之，就是經(jīng)常用到的列就最好創(chuàng)建索引。

不能使用引用：

a) 數(shù)據(jù)唯一性差（一個(gè)字段的取值只有幾種時(shí)）的字段不要使用索引

????????????比如性別，只有兩種可能數(shù)據(jù)。意味著索引的二叉樹級別少，多是平級。這樣的二叉樹查找無異于全表掃描

b) 頻繁更新的字段不要使用索引

????????????比如 logincount 登錄次數(shù)，頻繁變化導(dǎo)致索引也頻繁變化，增大數(shù)據(jù)庫工作量，降低效率

c) 字段不在 where 語句出現(xiàn)時(shí)不要添加索引,如果 where 后含 IS NULL /IS NOT NULL/ like ‘%輸入符%’等條件，不建議使用索引只有在 where 語句出現(xiàn)，mysql 才會去使用索引

d） where 子句里對索引列使用不等于（<>），使用索引效果一般

索引失效：

????????????a.如果條件中有 or，即使其中有條件帶索引也不會使用(這也是為什么盡量少用 or 的原因)

????????????????????????注意：要想使用 or，又想讓索引生效，只能將 or 條件中的每個(gè)列都加上索引

????????????b.對于多列索引，不是使用的第一部分，則不會使用索引

????????????c.like 查詢是以%開頭

????????????d.如果列類型是字符串，那一定要在條件中將數(shù)據(jù)使用引號引用起來 否則不使用索引

????????????e.如果 mysql 估計(jì)使用全表掃描要比使用索引快,則不使用索引

8，java 中的多線程在你們的這個(gè)項(xiàng)目當(dāng)中有哪些體現(xiàn)？

????????????a，后臺任務(wù)：如定時(shí)向大量(100W 以上)的用戶發(fā)送郵件；定期更新配置文件、任務(wù)調(diào)度

????????????????????????(如 quartz)，一些監(jiān)控用于定期信息采集

????????????b， 自動作業(yè)處理：比如定期備份日志、定期備份數(shù)據(jù)庫

????????????c， 異步處理：如發(fā)微博、記錄日志

怎樣進(jìn)行數(shù)據(jù)庫優(yōu)化？

a,選取最適用的字段

? ????????????????在創(chuàng)建表的時(shí)候，為了獲得更好的性能，我們可以將表中字段的寬度設(shè)得盡可能小。另外一個(gè)提高效率的方法是在可能的情況下，應(yīng)該盡量把字段設(shè)置為 NOTNULL，

b,使用連接（JOIN）來代替子查詢(Sub-Queries)

c,使用聯(lián)合(UNION)來代替手動創(chuàng)建的臨時(shí)表

d,事物：

????????????????? a)要么語句塊中每條語句都操作成功，要么都失敗。換句話說，就是可以保持?jǐn)?shù)據(jù)庫中數(shù)據(jù)的一致性和完整性。事物以 BEGIN 關(guān)鍵字開始，COMMIT 關(guān)鍵字結(jié)束。在這之間的一條 SQL 操作失敗，那么，ROLLBACK 命令就可以把數(shù)據(jù)庫恢復(fù)到 BEGIN 開始之前的狀態(tài)。

????????????????? b) 是當(dāng)多個(gè)用戶同時(shí)使用相同的數(shù)據(jù)源時(shí)，它可以利用鎖定數(shù)據(jù)庫的方法來為用戶提供一種安全的訪問方式，這樣可以保證用戶的操作不被其它的用戶所干擾。

e,鎖定表

f,使用外鍵

????????????????? 鎖定表的方法可以維護(hù)數(shù)據(jù)的完整性，但是它卻不能保證數(shù)據(jù)的關(guān)聯(lián)性。這個(gè)時(shí)候我們就可以使用外鍵。

g,使用索引

h,優(yōu)化的查詢語句

怎樣進(jìn)行數(shù)據(jù)庫性能調(diào)優(yōu)

?一應(yīng)用程序優(yōu)化

????????（1）把數(shù)據(jù)庫當(dāng)作奢侈的資源看待，在確保功能的同時(shí)，盡可能少地動用數(shù)據(jù)庫資源。

????????（2）不要直接執(zhí)行完整的 SQL 語法，盡量通過存儲過程實(shí)現(xiàn)數(shù)據(jù)庫操作。

????????（3）客戶與服務(wù)器連接時(shí)，建立連接池，讓連接盡量得以重用，以避免時(shí)間與資源的損耗。

????????（4）非到不得已，不要使用游標(biāo)結(jié)構(gòu)，確實(shí)使用時(shí)，注意各種游標(biāo)的特性。

二基本表設(shè)計(jì)優(yōu)化

（1）表設(shè)計(jì)遵循第三范式。在基于表驅(qū)動的信息管理系統(tǒng)中，基本表的設(shè)計(jì)規(guī)范是第三范式。

（2）分割表。分割表可分為水平分割表和垂直分割表兩種：水平分割是按照行將一個(gè)表分割為多個(gè)表。

（3）引入中間表。

三 數(shù)據(jù)庫索引優(yōu)化

索引是建立在表上的一種數(shù)據(jù)組織，它能提高訪問表中一條或多條記錄的特定查詢效率。

????聚集索引

????????????一種索引，該索引中鍵值的邏輯順序決定了表中相應(yīng)行的物理順序。聚集索引確定表中數(shù)據(jù)的物理順序。

????非聚集索引

????????????一種索引，該索引中索引的邏輯順序與磁盤上行的物理存儲順序不同

分布式開發(fā)面試問題

分布式架構(gòu) session 共享問題，如何在集群里邊實(shí)現(xiàn)共享。

? ? ? ? ?用了 CAS，所有應(yīng)用項(xiàng)目中如果需要登錄時(shí)在 web.xml 中配置過濾器做請求轉(zhuǎn)發(fā)到cas 端工作原理是在 cas 登錄后會給瀏覽器發(fā)送一個(gè)票據(jù)（ticket），瀏覽器 cookie 中會緩存這個(gè) ticket，在登錄其他項(xiàng)目時(shí)會拿著瀏覽器的 ticket 轉(zhuǎn)發(fā)到 cas，到 cas 后根據(jù)票據(jù)判斷是否登錄

項(xiàng)目中如何配置集群？

????????配置了 redis 集群，使用 redis3.0 版本官方推薦的配置方式

????????solr 集群使用了 solrCloud，使用 zookeeper 關(guān)聯(lián) solrCloud 的配置文件zookeeper 也配置了集群

????????應(yīng)用層使用 Nginx 負(fù)載均衡

對分布式，dubbo，zookeeper 說的不太清楚

分布式是從項(xiàng)目業(yè)務(wù)角度考慮劃分項(xiàng)目整個(gè)架構(gòu)?？梢詫㈨?xiàng)目基于功能模塊劃分再分別部署。Dubbo 是實(shí)現(xiàn)分布式項(xiàng)目部署框架。在 zookeeper 是 dubbo 分布式框架的注冊中心，管理服務(wù)的注冊和調(diào)用。

從前端到后臺的實(shí)現(xiàn)的過程描述的也不清楚

? 項(xiàng)目前端采用 angularjs 框架在 controller 控制器中完成數(shù)據(jù)組裝和數(shù)據(jù)展示，在服務(wù)層（service）代碼完成中后臺請求操作。后端基于前端的接口調(diào)用，完成數(shù)據(jù)的增刪改查操作。前后端數(shù)據(jù)交互通過 json 格式字符串完成。

Dubbo 為什么選擇 Zookeeper，而不選擇 Redis

回答：

引入了 ZooKeeper 作為存儲媒介，也就把 ZooKeeper 的特性引進(jìn)來。

????????首先是負(fù)載均衡，單注冊中心的承載能力是有限的，在流量達(dá)到一定程度的時(shí)候就需要分流，負(fù)載均衡就是為了分流而存在的，一個(gè) ZooKeeper 群配合相應(yīng)的 Web 應(yīng)用就可以很容易達(dá)到負(fù)載均衡；資源同步，單單有負(fù)載均衡還不夠，節(jié)點(diǎn)之間的數(shù)據(jù)和資源需要同步，ZooKeeper 集群就天然具備有這樣的功能；

????????命名服務(wù)，將樹狀結(jié)構(gòu)用于維護(hù)全局的服務(wù)地址列表，服務(wù)提供者在啟動 的時(shí)候，向 ZK 上的指定節(jié)點(diǎn)/dubbo/${serviceName}/providers 目錄下寫入自己的 URL 地址，這個(gè)操作就完成了服務(wù)的發(fā)布。 其他特性還有 Mast 選舉，分布式鎖等。

項(xiàng)目中 Zookeeper 服務(wù)器掛了，服務(wù)調(diào)用可以進(jìn)行嗎？

回答：

可以的，消費(fèi)者在啟動時(shí)，消費(fèi)者會從 zk 拉取注冊的生產(chǎn)者的地址接口等數(shù)據(jù)，緩存在本地。

每次調(diào)用時(shí)，按照本地存儲的地址進(jìn)行調(diào)用

ActiveMq 消息被重復(fù)消費(fèi)，丟失，或者不消費(fèi)怎么辦

回答：

重復(fù)消費(fèi)：Queue 支持存在多個(gè)消費(fèi)者，但是對一個(gè)消息而言，只會有一個(gè)消費(fèi)者可以消費(fèi)。

丟消息：用持久化消息，或者非持久化消息及時(shí)處理不要堆積，或者啟動事務(wù)，啟動事務(wù)后，commit()方法會負(fù)責(zé)任的等待服務(wù)器的返回，也就不會關(guān)閉連接導(dǎo)致消息丟失了。

不消費(fèi)：去 ActiveMQ.DLQ 里找找

怎樣解決 activeMQ 的消息持久化問題？

A：持久化為文件

????????? 這個(gè)你裝 ActiveMQ 時(shí)默認(rèn)就是這種，只要你設(shè)置消息為持久化就可以了。涉及到的配置和代碼有

????????????????<persistenceAdapter>

????????????????????<kahaDB directory="${activemq.base}/data/kahadb"/>

????????????????</persistenceAdapter>

????????????producer.Send(request, MsgDeliveryMode.Persistent, level, TimeSpan.MinValue);

B：持久化為 MySql

????加載驅(qū)動 jar，為數(shù)據(jù)中創(chuàng)建三個(gè)數(shù)據(jù)庫表，存儲 activemq 的消息信息

如果 activeMQ 的消息沒有發(fā)送成功，怎樣確保再次發(fā)送成功。

重新傳遞消息的情況

ActiveMQ 在接收消息的 Client 有以下幾種操作的時(shí)候，需要重新傳遞消息：

????1：Client 用了 transactions（事務(wù)），且在 session 中調(diào)用了 rollback()

????2：Client 用了 transactions，且在調(diào)用 commit()之前關(guān)閉

????3：Client 在 CLIENT_ACKNOWLEDGE 的傳遞模式下，在 session 中調(diào)用了 recover()

確保客戶端有幾種狀態(tài)，檢測狀態(tài)，只要提交了那就說明客戶端成功！

Zookeeper 怎樣進(jìn)行服務(wù)治理。

????接受提供者的接口信息和提供者 ip 地址進(jìn)行存儲，然后管理消費(fèi)者和提供者之間調(diào)用關(guān)系！

如果 activeMQ 的服務(wù)掛了，怎么辦？

????? 1、在通常的情況下，非持久化消息是存儲在內(nèi)存中的，持久化消息是存儲在文件中的，它們的最大限制在配置文件的<systemUsage>節(jié)點(diǎn)中配置。但是，在非持久化消息堆積到一定程度，內(nèi)存告急的時(shí)候，ActiveMQ 會將內(nèi)存中的非持久化消息寫入臨時(shí)文件中，以騰出內(nèi)存。雖然都保存到了文件里，但它和持久化消息的區(qū)別是，重啟后持久化消息會從文件中恢復(fù)，非持久化的臨時(shí)文件會直接刪除。

????2、考慮高可用，實(shí)現(xiàn) activemq 集群。

如果 zookeeper 服務(wù)掛了怎么辦？

? ? ????????注冊中心對等集群，任意一臺宕掉后，會自動切換到另一臺

????????????注冊中心全部宕掉，服務(wù)提供者和消費(fèi)者仍可以通過本地緩存通訊

????????????服務(wù)提供者無狀態(tài)，任一臺宕機(jī)后，不影響使用

????????????服務(wù)提供者全部宕機(jī)，服務(wù)消費(fèi)者會無法使用，并無限次重連等待服務(wù)者恢復(fù)

Dubbo 有 3 次重試，假如新消息被重復(fù)消費(fèi)怎么處理

回答：

????????1、去掉超時(shí)重試機(jī)制

? ? ? ? 2、服務(wù)端增加冪等校驗(yàn)，服務(wù)器加入校驗(yàn)機(jī)制，如果這個(gè)消息已被 消費(fèi)就不再重復(fù)消費(fèi)

mq 消費(fèi)者接收不到消息怎么辦。

Mq 消費(fèi)者接受不到消息存在 2 中情況：

1. 處理失敗 指的是 MessageListener 的 onMessage 方法里拋出 RuntimeException。

2. Message 頭里有兩個(gè)相關(guān)字段：Redelivered 默認(rèn)為 false，redeliveryCounter 默認(rèn)為 0。

3. 消息先由 broker 發(fā)送給 consumer，consumer 調(diào)用 listener，如果處理失敗，本地 redeliveryCounter++，給 broker 一個(gè)特定應(yīng)答，broker 端的 message 里 redeliveryCounter++，延遲一點(diǎn)時(shí)間繼續(xù)調(diào)用，默認(rèn)1s。超過 6 次，則給 broker 另一個(gè)特定應(yīng)答，broker 就直接發(fā)送消息到 DLQ。

4. 如果失敗 2 次，consumer 重啟，則 broker 再推過來的消息里，redeliveryCounter=2，本地只能再重試 4 次即會進(jìn)入 DLQ。

5. 重 試 的 特 定 應(yīng) 答 發(fā) 送 到 broker ， broker 即 會 在 內(nèi) 存 將 消 息 的 redelivered 設(shè) 置 為 true ，redeliveryCounter++，但是這兩個(gè)字段都沒有持久化，即沒有修改存儲中的消息記錄。所以 broker重啟時(shí)這兩個(gè)字段會被重置為默認(rèn)值。

系統(tǒng)的高并發(fā)問題是怎么解決的。

并發(fā)問題高，這個(gè)問題的解決方案是一個(gè)系統(tǒng)性的，系統(tǒng)的每一層面都需要做優(yōu)化：

1） 數(shù)據(jù)層

????a)? ?集群

????b) 分表分庫

????c) 開啟索引

????d) 開啟緩存

????e) 表設(shè)計(jì)優(yōu)化

????f) Sql 語句優(yōu)化

????g) 緩存服務(wù)器（提高查詢效率，減輕數(shù)據(jù)庫壓力）

????h) 搜索服務(wù)器（提高查詢效率，減輕數(shù)據(jù)庫壓力）

2） 項(xiàng)目層

????a) 采用面向服務(wù)分布式架構(gòu)（分擔(dān)服務(wù)器壓力，提高并發(fā)能力）

????b) 采用并發(fā)訪問較高的詳情系統(tǒng)采用靜態(tài)頁面

????c) 使用頁面緩存

????d) 用 ActiveMQ 使得業(yè)務(wù)進(jìn)一步進(jìn)行解耦，提高業(yè)務(wù)處理能力

????e) 使用分布式文件系統(tǒng)存儲海量文件

3） 應(yīng)用層

????a) Nginx 服務(wù)器來做負(fù)載均衡

????b) Lvs 做二層負(fù)載

并發(fā)數(shù)多少，項(xiàng)目中怎么解決并發(fā)問題？

面試中項(xiàng)目的并發(fā)數(shù)不宜說的過大，安裝目前品優(yōu)購項(xiàng)目拆分規(guī)模，這個(gè)項(xiàng)目的并發(fā)是在10000+，但是學(xué)生面試不能說的這么高。

可以有以下 2 方面的回答：

????1） 項(xiàng)目并發(fā)并不清楚（只是底層程序員）

????2） 參與核心業(yè)務(wù)設(shè)計(jì)，知道并發(fā)是多少（測試峰值，上線并發(fā)）3000---5000 吧

????面對項(xiàng)目高并發(fā)，項(xiàng)目必須做各種優(yōu)化措施了：

?4） 數(shù)據(jù)層

????a) 集群

????b) 分表分庫

????c) 開啟索引

????d) 開啟緩存

????e) 表設(shè)計(jì)優(yōu)化

????f) Sql 語句優(yōu)化

????g) 緩存服務(wù)器（提高查詢效率，減輕數(shù)據(jù)庫壓力）

????h) 搜索服務(wù)器（提高查詢效率，減輕數(shù)據(jù)庫壓力）

5） 項(xiàng)目層

????a) 采用面向服務(wù)分布式架構(gòu)（分擔(dān)服務(wù)器壓力，提高并發(fā)能力）

????b) 采用并發(fā)訪問較高的詳情系統(tǒng)采用靜態(tài)頁面

????c) 使用頁面緩存

????d) 用 ActiveMQ 使得業(yè)務(wù)進(jìn)一步進(jìn)行解耦，提高業(yè)務(wù)處理能力

????e) 使用分布式文件系統(tǒng)存儲海量文件

6） 應(yīng)用層

????a) Nginx 服務(wù)器來做負(fù)載均衡

????b) Lvs 做二層負(fù)載

消息發(fā)送失敗怎么處理，發(fā)送數(shù)據(jù)，數(shù)據(jù)庫已經(jīng)保存了數(shù)據(jù)，但是 redis 中沒有同步，怎么辦?；蛘哒f如何做到消息同步。

消息發(fā)送失敗，可以進(jìn)行消息的重新發(fā)送，可以配置消息的重發(fā)次數(shù)。

如果消息重發(fā)完畢后，消息還沒有接受成功，重啟服務(wù)。

Dubbo 的通信原理？

Dubbo 底層使用 hessain2 進(jìn)行二進(jìn)制序列化進(jìn)行遠(yuǎn)程調(diào)用

Dubbo 底層使用 netty 框架進(jìn)行異步通信。NIO

其他技術(shù)面試問題

單點(diǎn)登錄的訪問或者跨域問題

首先要理解什么是單點(diǎn)登錄。單點(diǎn)登錄是相互信任的系統(tǒng)模塊登錄一個(gè)模塊后，其他模塊不需要重復(fù)登錄即認(rèn)證通過。項(xiàng)目采用的是 CAS 單點(diǎn)登錄框架完成的。首先 CAS 有兩大部分?？蛻舳撕头?wù)端。服務(wù)端就是一個(gè) web 工程部署在 tomcat 中。在服務(wù)端完成用戶認(rèn)證操作。每次訪問系統(tǒng)模塊時(shí)，需要去 CAS 完成獲取 ticket。當(dāng)驗(yàn)證通過后，訪問繼續(xù)操作。對于 CAS 服務(wù)端來說，我們訪問的應(yīng)用模塊就是 CAS 客戶端。

跨域問題，首先明白什么是跨域。什么時(shí)候涉及跨域問題。當(dāng)涉及前端異步請求的時(shí)候才涉及跨域。那什么是跨域呢？當(dāng)異步請求時(shí)，訪問的請求地址的協(xié)議、ip 地址、端口號任意一個(gè)與當(dāng)前站點(diǎn)不同時(shí)，就會涉及跨域訪問。解決方案：1、jQuery 提供了 jsonp 實(shí)現(xiàn) 2、W3C 標(biāo)準(zhǔn)提供了 CORS（跨域資源共享）解決方案。

shiro 安全認(rèn)證時(shí)如何做的

要明白 shiro 執(zhí)行流程以及 shiro 的核心組件，可參考下圖

認(rèn)證過程：

在 application? Code 應(yīng)用程序中調(diào)用 subject 的 login 方法。將頁面收集的用戶名和密碼傳給安全管理器 securityManager，將用戶名傳給 realm 對象。Realm 對象可以理解為是安全數(shù)據(jù)橋，realm 中認(rèn)證方法基于用戶名從數(shù)據(jù)庫中查詢用戶信息。如果用戶存在，將數(shù)據(jù)庫查詢密碼返回給安全管理器 securityManager，然后安全管理器判斷密碼是否正確。

solr 的用途

solr 在系統(tǒng)中主要完成商品搜索功能，提高搜索性能。

分布式鎖的問題

針對分布式鎖的實(shí)現(xiàn)，目前比較常用的有以下幾種方案：

1.基于數(shù)據(jù)庫實(shí)現(xiàn)分布式鎖

2.基于緩存（redis，memcached，tair）實(shí)現(xiàn)分布式鎖

3.基于 zookeeper 實(shí)現(xiàn)分布式鎖

solr 索引中使用了 IK 分詞器，你們項(xiàng)目中使用到了分詞器的哪種工作模式？

IK 分詞器，基本可分為兩種模式，一種為 smart 模式，一種為非 smart 模式。

例如：張三說的確實(shí)在理

smart 模式的下分詞結(jié)果為：

張三 | 說的 | 確實(shí) | 在理

而非 smart 模式下的分詞結(jié)果為：

張三 | 三 | 說的 | 的確 | 的 | 確實(shí) | 實(shí)在 | 在理

可見非 smart 模式所做的就是將能夠分出來的詞全部輸出；smart 模式下，IK 分詞器則會根據(jù)內(nèi)在方法輸出一個(gè)認(rèn)為最合理的分詞結(jié)果，這就涉及到了歧義判斷。

項(xiàng)目中采用的是 smart 模塊分詞的。

java 中關(guān)于多線程的了解你有多少？線程池有涉及嗎？

同一類線程共享代碼和數(shù)據(jù)空間，每個(gè)線程有獨(dú)立的運(yùn)行棧和程序計(jì)數(shù)器(PC)，線程切換開銷小。線程分為五個(gè)階段：創(chuàng)建、就緒、運(yùn)行、阻塞、終止。

Java 線程有五種基本狀態(tài)

新建 狀態(tài)（New）：當(dāng)線程對象對創(chuàng)建后，即進(jìn)入了新建狀態(tài)，如：Thread t = new MyThread();

就緒狀態(tài)（Runnable）：當(dāng)調(diào)用線程對象的 start()方法（t.start();），線程即進(jìn)入就緒狀態(tài)。處于就緒狀態(tài)的線程，只是說明此線程已經(jīng)做好了準(zhǔn)備，隨時(shí)等待 CPU 調(diào)度執(zhí)行，并不是說執(zhí)行了 t.start()此線程立即就會執(zhí)行；

運(yùn)行狀態(tài)（Running）：當(dāng) CPU 開始調(diào)度處于就緒狀態(tài)的線程時(shí)，此時(shí)線程才得以真正執(zhí)行，即進(jìn)入到運(yùn)行狀態(tài)。注：就 緒狀態(tài)是進(jìn)入到運(yùn)行狀態(tài)的唯一入口，也就是說，線程要想進(jìn)入運(yùn)行狀態(tài)執(zhí)行，首先必須處于就緒狀態(tài)中；

阻塞狀態(tài)（Blocked）：處于運(yùn)行狀態(tài)中的線程由于某種原因，暫時(shí)放棄對 CPU 的使用權(quán)，停止執(zhí)行，此時(shí)進(jìn)入阻塞狀態(tài)，直到其進(jìn)入到就緒狀態(tài)，才 有機(jī)會再次被 CPU 調(diào)用以進(jìn)入到運(yùn)行狀態(tài)。根據(jù)阻塞產(chǎn)生的原因不同，阻塞狀態(tài)又可以分為三種：

1.等待阻塞：運(yùn)行狀態(tài)中的線程執(zhí)行 wait()方法，使本線程進(jìn)入到等待阻塞狀態(tài)；

2.同步阻塞 -- 線程在獲取 synchronized 同步鎖失敗(因?yàn)殒i被其它線程所占用)，它會進(jìn)入同步阻塞狀態(tài)；

3.其他阻塞 -- 通過調(diào)用線程的 sleep()或 join()或發(fā)出了 I/O 請求時(shí)，線程會進(jìn)入到阻塞狀態(tài)。當(dāng) sleep()狀態(tài)超時(shí)、join()等待線程終止或者超時(shí)、或者 I/O 處理完畢時(shí)，線程重新轉(zhuǎn)入就緒狀態(tài)。

死亡狀態(tài)（Dead）：線程執(zhí)行完了或者因異常退出了 run()方法，該線程結(jié)束生命周期。

Java 中線程的創(chuàng)建常見有如三種基本形式

1.繼承 Thread 類，重寫該類的 run()方法。

2.實(shí)現(xiàn) Runnable 接口，并重寫該接口的 run()方法，該 run()方法同樣是線程執(zhí)行體，創(chuàng)建 Runnable 實(shí)現(xiàn)類的實(shí)例，并以此實(shí)例作為 Thread類的 target 來創(chuàng)建 Thread 對象，該 Thread 對象才是真正的線程對象。

3.使用 Callable 和 Future 接口創(chuàng)建線程。

具體是創(chuàng)建 Callable 接口的實(shí)現(xiàn)類，并實(shí)現(xiàn) clall()方法。并使用 FutureTask 類來包裝 Callable 實(shí)現(xiàn)類的對象，且以此 FutureTask 對象作為 Thread 對象的 target 來創(chuàng)建線程。

線程池：線程池是一種多線程處理形式，處理過程中將任務(wù)添加到隊(duì)列，然后在創(chuàng)建線程后自動啟動這些任務(wù)。線程池線程都是后臺線程。每個(gè)線程都使用默認(rèn)的堆棧大小，以默認(rèn)的優(yōu)先級運(yùn)行，并處于多線程單元中。如果某個(gè)線程在托管代碼中空閑（如正在等待某個(gè)事件）,則線程池將插入另一個(gè)輔助線程來使所有處理器保持繁忙。如果所有線程池線程都始終保持繁忙，但隊(duì)列中包含掛起的工作，則線程池將在一段時(shí)間后創(chuàng)建另一個(gè)輔助線程但線程的數(shù)目永遠(yuǎn)不會超過最大值。超過最大值的線程可以排隊(duì)，但他們要等到其他線程完成后才啟動。

如何實(shí)現(xiàn)線程的同步？

為何要使用同步？

? java 允許多線程并發(fā)控制，當(dāng)多個(gè)線程同時(shí)操作一個(gè)可共享的資源變量時(shí)（如數(shù)據(jù)的增刪改查），將會導(dǎo)致數(shù)據(jù)不準(zhǔn)確，相互之間產(chǎn)生沖突，因此加入同步鎖以避免在該線程沒有完成操作之前，被其他線程的調(diào)用，從而保證了該變量的唯一性和準(zhǔn)確性。

線程同步（5 種同步方式）

1.同步方法 2.同步代碼塊 3.使用特殊域變量(volatile)實(shí)現(xiàn)線程同步 4.使用重入鎖實(shí)現(xiàn)線程同步 5.使用局部變量實(shí)現(xiàn)線程同步

遍歷 hashmap 有幾種方式？

Map 的四種遍歷方式

(1) for each map.entrySet()

(2) 顯示調(diào)用 map.entrySet()的集合迭代器

(3) for each map.keySet()，再調(diào)用 get 獲取

(4) for each map.entrySet()，用臨時(shí)變量保存 map.entrySet()

簡單介紹一下 solr 全文檢索在整個(gè)系統(tǒng)中的應(yīng)用，在更新索引庫的同時(shí)會產(chǎn)生索引碎片，這個(gè)碎片是如何處理的？

根據(jù)商品的名稱，分類，品牌等屬性來創(chuàng)建索引進(jìn)行商品搜索。

更新索引庫時(shí)會先刪除索引，然后再重建。而對于刪除聚集索引，則會導(dǎo)致對應(yīng)的非聚集索引重建兩次(刪除時(shí)重建，建立時(shí)再重建).

直接刪除碎片。

java 并發(fā)包下有哪些并發(fā)組件？

分為兩層組成

外層框架主要有 Lock(ReentrantLock、ReadWriteLock 等)、同步器（semaphores 等）、阻塞隊(duì)列

（BlockingQueue 等）、Executor（線程池）、并發(fā)容器（ConcurrentHashMap 等）、還有 Fork/Join 框架；

? 內(nèi)層有 AQS（AbstractQueuedSynchronizer 類，鎖功能都由他實(shí)現(xiàn)）、非阻塞數(shù)據(jù)結(jié)構(gòu)、原子變量類(AtomicInteger 等無鎖線程安全類)三種。

講一下 jvm 調(diào)優(yōu)。

a,堆大小設(shè)置

b,回收器選擇

c,輔助信息

JVM 提供了大量命令行參數(shù)，打印信息，供調(diào)試使用；

講一下 jvm 的組成。

JVM 由類加載器子系統(tǒng)、運(yùn)行時(shí)數(shù)據(jù)區(qū)、執(zhí)行引擎以及本地方法接口組成

講一下 ThreadLocal 類。

? ThreadLocal，很多地方叫做線程本地變量，也有些地方叫做線程本地存儲，其實(shí)意思差不多。可能很多朋友都知道 ThreadLocal 為變量在每個(gè)線程中都創(chuàng)建了一個(gè)副本，那么每個(gè)線程可以訪問自己內(nèi)部的副本變量；

ThreadLocal 在每個(gè)線程中對該變量會創(chuàng)建一個(gè)副本，即每個(gè)線程內(nèi)部都會有一個(gè)該變量，且在線程內(nèi)部任何地方都可以使用，線程之間互不影響，這樣一來就不存在線程安全問題，也不會嚴(yán)重影響程序執(zhí)行性能。

但是要注意，雖然 ThreadLocal 能夠解決上面說的問題，但是由于在每個(gè)線程中都創(chuàng)建了副本，所以要考慮它對資源的消耗，比如內(nèi)存的占用會比不使用 ThreadLocal 要大；

Solr 熱搜索

回答：

和 Redis 熱搜索一樣將經(jīng)常搜索的詞，新建 collection，對這些搜索內(nèi)容單獨(dú)進(jìn)行索引。

簡單介紹一下 solr 全文檢索在整個(gè)系統(tǒng)中的應(yīng)用，在更新索引庫的同時(shí)會產(chǎn)生索引碎片，這個(gè)碎片是如何處理的？

根據(jù)商品的名稱，分類，品牌等屬性來創(chuàng)建索引進(jìn)行商品搜索。

更新索引庫時(shí)會先刪除索引，然后再重建。而對于刪除聚集索引，則會導(dǎo)致對應(yīng)的非聚集索引

重建兩次(刪除時(shí)重建，建立時(shí)再重建).

直接刪除碎片。

怎么確保 session 共享？

在分布式項(xiàng)目中實(shí)現(xiàn) session 共享必須做以下準(zhǔn)備工作：

1） Cookie 中共享 ticket

2） Redis 存儲 session

分布式系統(tǒng)共享用戶身份信息 session，必須先獲取 ticket 票據(jù)，然后再根據(jù)票據(jù)信息獲取 redis 中用戶身份信息。

實(shí)現(xiàn)以上 2 點(diǎn)即可實(shí)現(xiàn) session 共享。

目前項(xiàng)目中使用的 springsecurity + cas 來實(shí)現(xiàn)的單點(diǎn)登錄，cas 自動產(chǎn)生 ticket 票據(jù)信息，每次獲取

用戶信息，cas 將會攜帶 ticket 信息獲取用戶身份信息。

項(xiàng)目中哪塊涉及了線程問題，怎么處理的？

項(xiàng)目的高并發(fā)訪問就是一個(gè)多線程問題。

項(xiàng)目中普通的業(yè)務(wù)開發(fā)基本沒有涉及多線程問題，不過你可以談?wù)勀闶褂玫目蚣苤惺褂玫亩嗑€程技術(shù)：

因?yàn)槲覀冺?xiàng)目使用的框架進(jìn)行開發(fā)的，因此多線程處理多讓框架非我們處理結(jié)束了。

1） 高并發(fā)就是多線程，這里的多線程讓 servlet 服務(wù)器給處理了談?wù)?Tomcat 多線程配置;

????a) 配置線程池，擴(kuò)大并發(fā)能力

????b) 開啟 NIO 能力等等

2） 框架多線程：mybatis 框架底層使用的連接池

傳統(tǒng) IO 和 NIO 的區(qū)別？

IO 是直接通信

NIO 是由緩存作為中間層，先把數(shù)據(jù)放入緩存（內(nèi)存），數(shù)據(jù)的消防者可以從緩存中獲取數(shù)據(jù)。