Get kicked Tribal story (+): How to fill in the Java pit?

There is no pit in the world, and the man who treads on it becomes a pit. Every difficulty encountered, every step of a pit, for the programmer is a wealth. Continuous learning is the source of the programmer's ability to remain competitive. This issue will share a trampling of countless Java program ape pits cheats.

Elm, a lot of experience (trampling) technology otaku, like to learn new technology but do not love to study the new technology (because lazy, ape the role of the opposite). Since graduating in 14, in the Java development of this road can be described as a lot of people, also buried a lot of pits, also have been pits several times. Because of laziness, there is no too many notes on the problems he has encountered (it is a good habit to document some of the tricky questions), just to analyze why such problems arise and how we should avoid repetition. Here Elm share for the first time to do independent needs of the process.

Elm Java Development Engineer

To become a qualified Java Program ape, the independent completion of the requirements is a must go through the stage, in the process may encounter a lot of problems, to learn the rational use of resources (official documents, community forums, etc.) to solve the problem. At this stage, it should be the most pit, the most harvested, the fastest growing stage.

In the first 3 months of the Elm's entry, the job was to fix bugs and improve demand, and he didn't need to think too much, according to what the client said. Three months later, his company successfully took the customer's two-phase project, due to insufficient manpower, coupled with his in the first phase of the maintenance of the business more familiar with, the eldest brother let Elm alone to bear the project front subsystem of the full demand. At first, Elm was very excited, and it came with a lot of confusion.

How do elm and pits the pit? Share some of his experiences and hopefully help the developers.

How to open two SVN services at the same time

Because the company's resources are not enough, the eldest brother asked in the original server to get another SVN service, so he began various churn, but no matter what is no way to get up at the same time two services. What to do, can only find brother (Google) help, because the SVN service start (/etc/init.d/svnserve start) is to include some default parameters, such as--listen-port specified service port default is 3691, If you want to start at the same time two SVN services only need to specify two different listen-port on startup OK.

The problem is resolved as follows:

/etc/init.d/svnserve start-d-r/svn/repo First library start default 3691/etc/init.d/svnserve--listen-port 9999-d-r/svn/svndata The second time the specified port is started

Problem fix, followed by the tension of the code development, things a little unexpected smooth, the backend interface successfully completed through testing, Elm start and front-end docking joint adjustment, good excitement, can not get ahead of the task. The crackling was finished and the test began.

Fastjson Serialization Problems

The so-called not encountered the bug program Ape is not a normal program ape, not surprisingly, the problem came. When the same object is assigned to a different key in HashMap to the front end, the second value cannot be parsed correctly .... He wrote the code must not be counseling, there is a problem to solve the problem, so Elm began to find the problem, began to simulate the data, found that the return results are as follows:

{"O1": {"age": +, "name": "O1"}, "2": {"$ref": "$.o1"}}

public static  Void test1 ()  {         testobject object =  new testobject ("O1",  16);          map<string,  TestObject> map = new HashMap<String, TestObject> ();          map.put ("O1",  object);          map.put ("O2",  object);          System.out.println (new string (json.tojsonbytes (map));      } 

Output: {"O1": {"age": +, "name": "O1"}, "O2": {"$ref": "$.o1"}}

When there are multiple identical data in a collection object, when the Ist collection object is converted to a JSON object output to the foreground, JSON defaults to the second data processing with "$ref": "$.object" .< here object refers to the first data;  This JSON conversion results output to the foreground must not be used, fortunately, JSON has to provide a way to prohibit the closed reference loop detection, only need to add serializerfeature.disablecircularreferencedetect when the conversion It can be solved. The modified code is as follows:

public static  Void test1 ()  {        testobject object = new  testobject ("S1",  16);         map<string, testobject > map = new HashMap<String, TestObject> ();         map.put ("O1",  object);         map.put ("O2",  object);        serializerfeature feature =  serializerfeature.disablecircularreferencedetect;         System.out.println (New string (Json.tojsonbytes (map, feature)));     } 

The output is as follows: {"O1": {"age": +, "name": "O1"}, "O2": {"age": +, "name": "O1"}}

The problem is solved here. Soon afterwards the test passed, delivered the customer beta version, started and the central tuning test.

Oom Exception Handling

Elm thought it was all right to get here, but it was impossible. After two days of the test, customer feedback said: "Our XXX message data has been sent to the center, but the center said they did not receive, you check what is the problem bai!" "The Customer is God, Elm and his colleagues started querying the logs and found some oom exceptions. The scene of the anomaly is to take the data-group message-MQ forward this link, and then start a one-point troubleshooting.

The possible reasons for Elm's first thought are:

1, data out to generate a message this process is done in memory, will it be too much data here?

2. Will the message generation process produce too many objects to be recycled?

3, will the data sent slower than the speed of the message generation to cause the waiting queue full?

Then began the targeted modification test, he will be a one-time data generation of the process of generating messages into batches to do, and then test run for a period of no problem (excluding 1), in the formation of insulation process, each converted object is placed into an empty object=null, in order to timely recovery, There is no problem with the test running for a while (excluding 2); on the 3rd, the first thing he wants to do is increase the number of threads (the server turns on Hyper-threading, the number of threads in the app) to increase the processing rate, and after a period of time the Oom will appear. What do we do? Back on the waiting queue again, can you limit the waiting queue to a certain extent? Elm then increases the depth of the wait queue before each message is taken from MQ, discarding the processing of this MQ queue message if the depth is greater than twice times the maximum number of threads. Then continue the test and the problem does not appear again.

What if the query is slow?

The final project is on the line and can finally breathe a sigh of relief. But one day, the boss of Elm said the customer reflects part of the query is very slow, let him deal with it. Elm thought, this should be a small problem, to index the data sheet can be done. To the customer site after the discovery, the original table is indexed, can query or slow, only to find the reason. Have to say, explain SQL is a good command, found that the index does not take effect, after careful comparison, found that the associated query associated fields in two tables are indexed, two tables of the character set are UTF8, but the collation of one is utf-bin (binary storage data, case-sensitive), One is utf8_general_ci (case insensitive), so the data collation changes to the consistent index to take effect, the query speed is up.

Description of collation of UTF-8 encoding in Ps:mysql

Utf8_bin stores each character in a string with binary data, which is case-sensitive.

Utf8_genera_ci is case-insensitive, CI is the abbreviation for case insensitive, which is casing insensitivity.

The Utf8_general_cs is case-sensitive, and CS is a case-sensitive abbreviation, that is, uppercase and lowercase.

"Write at the end"

Elm tidied up the pits for the years, giving himself some inspiration and encouragement to his little friends who are struggling with him in the pit. Continuous learning is a prerequisite for maintaining competitiveness, and a solid foundation is an advanced stepping stone. Look up and not walk Alone (Exchange), dry (code), even if called the cock Silk, but also want to have a dream, in case of a reverse attack.

If you are willing to share your story, please add 51CTO Developer QQ Exchange Group 114915964 Contact Group master Xiao Guan, look forward to your wonderful story!

Get kicked Tribal story (+): How to fill in the Java pit?