Предполагая, что файл содержит динамические и неизвестные ключи и значения, и вы не можете смоделировать их в своем приложении. Затем вы можете сделать что-то вроде:
func main() {
if os.Args[1] == "update-json-from-json" {
...
jsonFile := readInput()
var jsonKeys interface{}
err := json.Unmarshal(jsonFile, &jsonKeys)
functions.Check(err)
...
}
}
, чтобы загрузить содержимое в empty interface
, а затем использовать библиотеку го отражения ( https://golang.org/pkg/reflect/ [ 113]) для перебора полей, поиска их имен и значений и обновления их в соответствии с вашими потребностями.
Альтернативой является Unmarshal в map[string]string
, но это не очень хорошо справится с вложенным JSON, хотя это может (но я не проверял это).
Чтобы понять, что происходит, вы должны попытаться запустить его под профилировщиком. Попробуйте YourKit ( http://www.yourkit.com/ ) или Netbeans ( http://profiler.netbeans.org/docs/help/5.5/profile_j2ee_profileproject.html ) .
YourKit one лучше интегрирован с tomcat.
Если вы используете 75% ЦП и не понимаете почему, я предлагаю вам запустить kill -3 для процесса tomcat (ctrl-break, если у вас есть консоль), чтобы получить дамп потока (когда нагрузка высокая!). По моему опыту, большинство потоков должно быть в режиме ожидания или в режиме ожидания. Ищите любую отдельную ветвь кода, которая повторяется в следах стека, и это ваш вероятный виновник (не-io ждет!). Это «профиль бедняков», который зачастую является лучшим и наиболее эффективным способом решения этих проблем.
Лямбда-зонд - очень удобный инструмент для мониторинга Tomcat.
Используете ли вы четырехъядерную систему? Вероятно, Tomcat работает на 100% в 3 из них. Сначала я бы проверил наличие бесконечного цикла или чего-то подобного в приложении.
Это, скорее всего, вызвано приложениями, которые вы запускаете поверх tomcat. Конечно, если у вас очень высокий трафик в ваших приложениях, это также может быть причиной.
Во всех ответах рассказывается, как поставить точный диагноз, кроме того, я бы добавил, что из моего опыта бесконечный цикл в одном из ваших приложений, вероятно, является виновником.
Как J -16 SDiZ сказал, что лучше всего запустить профилировщик, чтобы сузить проблему до одного приложения.
Прежде всего (это относится ко всем Java-приложениям) вы должны определить, какой поток используя CPU. Это возможно в JDK 1.6. Это делается с помощью java.lang.management.ManagementFactory.getThreadMXBean (). Вот пример использования (JSP):
<%@ page import="java.lang.management.*, java.util.*" %>
<%!
Map cpuTimes = new HashMap();
Map cpuTimeFetch = new HashMap();
%><%
long cpus = Runtime.getRuntime().availableProcessors();
ThreadMXBean threads = ManagementFactory.getThreadMXBean();
long now = System.currentTimeMillis();
ThreadInfo[] t = threads.dumpAllThreads(false, false);
for (int i = 0; i < t.length; i++) {
long id = t[i].getThreadId();
Long idid = new Long(id);
long current = 0;
if (cpuTimes.get(idid) != null) {
long prev = ((Long) cpuTimes.get(idid)).longValue();
current = threads.getThreadCpuTime(t[i].getThreadId());
long catchTime = ((Long) cpuTimeFetch.get(idid)).longValue();
double percent = (current - prev) / ((now - catchTime) * cpus * 10000);
if (percent > 0 && prev > 0) {
out.println("<li>" + t[i].getThreadName() + " " + percent + " (" + prev + ", " + current + ")");
}
}
cpuTimes.put(idid, new Long(current));
cpuTimeFetch.put(idid, new Long(now));
}
%>
После этого вы можете получить дамп потока и проанализировать код в этом потоке, чтобы исправить чрезмерную загрузку ЦП.