Record several Java development interview questions

​

The basis for indexing

1. The primary key and foreign key of the table must have indexes.

2. Tables with more than 300 data should have indexes.

3. For tables that are often connected with other tables, the connection fields should have indexes.

4. The fields that often appear in the where statement, especially the fields of large tables, should be indexed.

5. It is often necessary to build an index on the field for range search, because the index has been sorted, and the specified range is continuous.

6. The fields that often need to be sorted are indexed, because the index is already sorted.

7. Create an index for the fields that often appear behind order by, group by, and distinct.

8. Indexes should be built on small fields. For large text fields and super long fields, do not build indexes.

9. If it always appears in the where statement at the same time, you can consider building a composite index, otherwise it will be decomposed into multiple single-field indexes.

10. The composite index should put the fields with high application degree in front.

11. The more indexes the better, too many indexes will affect the performance of writing data.

Citation:

https://blog.csdn.net/cherry_xiu/article/details/79456872

https://www.cnblogs.com/net-study/p/3397359.html

https://www.cnblogs.com/s-b-b/p/8334593.html

Under what circumstances will the index be invalid

1. If there is or in the condition, even if there is an index in the condition, it will not be used (all condition fields must be indexed).

2. For a compound index, the field in front of the order is not included in the condition, and the index will not be used.

3. Indexes will not be used if the like query starts with %.

4. If the null value is used for judgment, the index will become invalid.

5. Indexes will not be used when !=, <>, in, not, and not exists symbols are used.

6. When using an expression or function on the left side of = in the where clause, the index will not be used.

7. Column-to-column comparisons do not use indexes.

8. The index will not be used when the data types on both sides of the where clause are inconsistent.

Citation:

https://zhuanlan.zhihu.com/p/58269930

https://www.jianshu.com/p/f4fb6b68e180

Reasons for spring transaction failure

1. The database engine does not support transactions, such as MyISAM of mysql.

2. The current class is not managed by Spring.

3. The method is not public.

4. Calls between different methods in the same class.

5. The data source does not have a transaction manager configured.

6. Actively does not support transactions, Propagation.NOT_SUPPORTED.

7. The exception is caught but not thrown.

8. The exception type is inconsistent, rollbackFor = Exception.class.

Citation:

https://www.cnblogs.com/javastack/p/12160464.html

How to avoid deadlock

1. Banker's Algorithm.

2. Avoid multiple locks.

3. Set the same locking sequence.

4. Use a timer lock.

5. Use algorithms for deadlock detection.

Citation:

https://blog.csdn.net/weixin_42228338/article/details/97686461

https://blog.csdn.net/wuhuagu_wuhuaguo/article/details/79653840

Between integers == when is true and when is false

1. The comparison between two Integer variables generated by new will always be false.

2. When comparing an Integer variable with an int variable, as long as the values are equal, it is true.

3. The Integer generated by non-new is compared with the Integer generated by new, and the result is false.

4. Comparing two Integers not generated by new, if the value range is -128~127, then it is true, otherwise it is false.

Citation:

https://blog.csdn.net/zjfahs/article/details/90138277

https://baijiahao.baidu.com/s?id=1649795543571026301&wfr=spider&for=pc

What are the application scenarios of redis

1. Hot data cache (such as: session, token).

2. Timer (expire).

3. Counter (incrby).

4. Leaderboard (SortedSet).

5. Distributed lock and single thread mechanism.

6. Simple queue (list push, list pop).

7. Publish/subscribe (publish, subscribe).

8. Fixed-length up-to-date lists (lpush, ltrim).

9. Bit operations (setbit, getbit, bitcount).

Citation:

https://www.cnblogs.com/wadhf/p/11799419.html

https://www.cnblogs.com/NiceCui/p/7794659.html

The composition of the HTTP protocol

1.Request information

1. Request line, including: method, path, http version

2. Request header, including: Accept, Accept-Encoding, Connection, Host, User-Agent and other information.

3. Request message body, common formats: application/x-www-form-urlencoded, multipart/form-data, application/json.

2.Response information

1. Response line, including: http version, status code, description.

2. Corresponding headers, including: Connection, Content-Type, Set-Cookie and other information.

3. Response message body, common formats: application/x-www-form-urlencoded, multipart/form-data, application/json.

Citation:

https://www.cnblogs.com/superfeeling/p/11561340.html

https://blog.csdn.net/weixin_33984032/article/details/88834948

The lifecycle of the HTTP protocol

1.Three-way handshake

1. The first handshake: the client actively sends a SYN packet to the server, and enters the SYN_SEND state, waiting for the server to confirm.

2. The second handshake: the server receives the SYN packet and confirms it, sends SYN+ACK to the client, and the server enters the SYN_RECV state.

3. The third handshake: The client receives the SYN+ACK packet and sends ACK to confirm the connection. After sending, the client and server enter the ESTABLISHED state and complete the three-way handshake.

2.The client sends an HTTP request message.

3.The server returns an HTTP response message.

4.Wave four times

1. The first wave: the client sends a FIN packet, telling the server to close the connection and enter the FIN_WAIT_1 state.

2. The second wave: After receiving the FIN packet, the server sends an ACK to tell the client that the close request has been received, but it is not ready yet. The server enters the CLOSE_WAIT state. After receiving the packet, the client enters FIN_WAIT_2 and waits for the server to close the connection.

3. The third wave: After the server is ready to close, it sends a FIN packet to tell the client that it is ready to close. After the sending is completed, the server enters the LAST_ACT state and waits for the client to confirm.

4. The fourth wave: After receiving the close request, the client sends an ACK packet to the server, and enters the TIME_WAIT state, waiting for the ACK packet that the server may request to retransmit. After receiving the ACK packet, the server closes the connection and enters the CLOSED state. After waiting for a fixed time (two maximum life cycles), the client does not receive the ACK packet from the server, thinks that the server is closed, and closes the connection itself, entering the CLOSED state.

Citation:

https://blog.csdn.net/grl18840839630/article/details/80851479

https://www.jianshu.com/p/12790cea57ac